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Abstract 


This  study  investigaied  the  results  of  measuring  software  support  of  Oracle  database  applications  and 
estimating  the  effort  and  schedule  required  to  provide  sqjport  Software  measurement  was  accomplished 
with  a  variant  cS  the  function  points  metric,  called  Mark  II  fimction  points,  which  is  comprised  of  three 
weighted  parameters,  inputs,  entities,  and  ouqnits.  A  technique  for  mapping  Mark  n  function  points  to 
Oracle  DBMS  components  was  developed,  and  the  size  of  the  software  siqiport  fr each  project,  per  team, 
was  measured  by  tabulating  and  weighting  the  number  of  inputs,  entities,  and  ouq)uts  that  are  added, 
changed,  andA>r  deleted.  Software  support  effort  was  measured  in  work-hours  and  schedule  in  caloidar- 
weeks  for  given  levels  of  function  points.  A  data  collection  program  was  written  to  assist  with  tabulating 
the  measurements  and  also  provided  an  option  for  sizing  the  siq)port  by  analogy.  Observations  were 
collected  for  12  projects  ranging  up  to  SO  function  points.  The  relationship  between  software  siqipoit 
measurement  in  Mark  II  function  points  and  the  resulting  effort  or  schedule  was  extensively  analyzed  for 
one  and  two  person  teams.  A  relationship  determined  by  regression  analysis  was  shown  to  be  statistically 
significant  for  both  effwt  and  schedule. 
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SOFTWARE  SUPPORT  MEASUREMENT  AND  ESTIMATING  FOR  ORACLE 
DATABASE  APPUCATIONS  USING  MARK  H  FUNCTION  POINTS 

L  Introdttctioii 


1.1  Backgrouad 

A  critical  challenge  for  software  support  organizations  is  the  management  changes  to  the  siqiported 
system.  Software  projects  are  conducted  according  to  a  plan  based  on  an  estimate  of  the  size  of  the  project 
The  Irian  describes  the  expected  schedule  and  effort  needed  to  provide  the  strfiware  support 

The  Air  FOtce  Institute  of  Ibchnology  has  its  own  software  siq)pott  organization,  the  Systems  Support 
Division  (AFTT/SCV),  that  provides  computer  sigjpcxtto  the  Institute.  SCV  manages  all  of  AFIT’s  software 
requirements  for  communications-computer  systems  including  studies,  analyses,  requirements  definition, 
design,  development  documentation,  testing,  imiriementation,  and  training  on  unique  software  applications. 
SCV  conducts  software  project  stauis  briefings  for  senior  AFTT  staff.  They  also  assure  that  computer  support 
contractors  perform  in  compliance  with  all  pertinent  communications<computa'  systems  regulations  and 
the  Quality  Assurance  Surveillance  Plan  (35:1).  Hiis  research  wiU  focus  on  SCV’s  software  support  to 
tpplications,  using  a  cotmnercial  relational  database  management  system  (DBMS)  by  Oracle  oorporatioa 
The  DBMS  includes  a  database  engine  that  relates  records  cri’  data  to  one  another  and  it  provides  several 
software  tools  to  access  the  database.  Some  of  the  tools  are  SQL*PIus,  SQL*FiQnns,  and  SQL*Reports. 

The  database  query  language  that  is  used  is  SQL*Plos.  which  is  an  extension  of  the  Structured  Query 
Language  (SQL)  as  defined  by  the  International  Business  Machines  corporatioiL  SQL  is  a  non-procedural 
data  access  Imiguage.  The  term  ’non-procedural’  mems  that  the  programmer  does  not  have  u>  speafy  Otc 
procedure  for  accessing  data,  but  instead  ordy  has  to  qrecify  what  data  is  to  be  accessed  (30:213).  For 
example,  there  are  no  ’if-then-else’  constructs  and  no  means  for  making  tettqxnry  computations. 

SQL*Fbtnis  is  a  fourdi  generation  qrplication  developmem  language  (40L)  that  streamlines  the 
software  devdopment  process  by  generating  most  of  the  user  interface  input  and  output  software  details 
for  the  programmer,  as  well  as  data  access.  Tourth  generatioo  languages  are  defined  as  those  that  ate  non¬ 
procedural  in  nature  and  end-user  (requirements  and  specifications)  oriented"  (3:149).  This  oonrespondenoe 
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faciliuaes  the  paititioiiing  of  the  software  siq>port  requireinent  into  meaningful  software  units  of  measure. 
A  consequence  of  the  ease  of  use  of  40Ls  is  that  they  tend  to  restrict  the  variety  of  solutions,  which  creates 
a  close  conespondence  between  the  source  code  produced  by  the  applications  generator  and  the  software 
requirement  itself.  This  allows  the  programmer  to  focus  on  assenibling  the  functions  diat  were  requested 
by  the  user  of  the  database  applications.  SQL*Fonn8  produces  mteractive  'forms’  that  allow  the  user  to 
store  and  retrieve  data.  SCV  uses  version  2.3  of  SQL*Forms.  Another  tool.  SQL*Rqxxts.  extracts  records 
firom  the  database  and  formats  the  ouqxiL  SCV  provides  Oracle  database  software  support  by  enhancing 
the  forms  or  rqxxts  that  access  the  database. 

1.2  Spedfk  Problem 

Recent  changes  in  the  AFTT/SC V  software  sunxxt  environment  requires  SCV  to  more  effectively  use 
available  resources.  Historically.  SCV  has  relied  upon  expert  judgement  to  estimate  project  schedules,  but 
is  now  faced  with  tighter  budget  constraints,  requiring  the  same  level  of  siqiport  with  fewer  resources.  The 
budget  constraints  have  forced  SCV  to  reduce  its  contracted  siqiport  strength  fiom  seven  to  two  analysts, 
lb  partially  compensate,  SCV  had  a  net  increase  in  enlisted  programmer  support  fiom  five  to  six,  as  a  result 
of  two  NCOS  leaving  and  three  airmen  arriving.  Hie  loss  of  the  contractor  support  also  represents  a  loss  of 
the  expertise  on  which  project  estimates  are  based,  requiring  newly  trained  enlisted  programmers  to  make 
estimates,  lb  meet  this  need,  the  Chief  of  the  Systmns  Support  Division  has  requested  that  thesis  research 
be  done  in  the  area  of  software  stpport  measurement  and  estimating  (34:151).  Given  a  requirement  to 
change  an  existing  Oracle  database  qiplication,  SCV  needs  to  be  able  to  predict  how  long  it  will  take  to 
deliver  the  change,  so  that  planning  and  contracting  decisions  can  be  expedited.  Consequently.  SCV  would 
like  to  make  accurate  estimates  of  project  size,  effort  and  schedule. 

U  Research  Objective  and  Investigative  Qnestioas 

The  research  objective  is:  to  estimate  the  expected  siqiport  effort  and  schedule  given  the  size  of  an 
Oracle  datal»se  software  sipport  request.  The  investigative  questions  that  directed  this  researdi  are: 

•  What  is  the  most  meaningful  software  size  measure? 

•  How  much  effort  and  schedule  is  required  for  given  leveb  of  software  support? 

•  What  is  the  relationshqi  between  the  size  and  effort  or  schedule? 
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L4  Scope  and  Limitatioiis 


Only  strftware  siqiport  for  Oracle  database  systems  was  tracked  during  the  three-month  data 
collection  period  of  this  thesis.  During  this  period,  SCV  was  staffed  with  new  contractofs  and  several 
new  enlisted  programmers,  but  no  government  civilian  ptogrammen.  System  accounting  data  relevant 
to  project  activities  was  not  odlected  because  automatic  accounting  is  not  activated  in  the  SCV  Oracle 
environmertt.  The  software  baseline  si^ported  by  SCV  has  no  documentation  or  formal  review  process, 
and  is  managed  as  sqiatate  development  and  operatknal  baselines. 

L5  Defiaitioiis  for  Measurencat 


•  Analogy:  characterizing  the  size  of  software  to  be  developed  relative  to  existing  software. 

•  Block:  SQL*Fotms  components  that  are  based  on  database  taUes. 

•  Calendar-week:  the  period  of  time  that  a  software  support  project  was  open  fiom  start  to  finish. 

•  Entity:  "is  anything  (object,  real,  or  atetiact)  in  the  teal  world  about  which  the  system  provides 
information"  (32:4). 

•  Environmental  factors:  any  features  about  an  organization  or  project  other  than  size  that  may 
influence  effort  and  schedule. 

•  Field:  data  items  that  are  disi^yed  on  the  screen  or  printed  in  a  rqxnL 

•  4GL:  Fourth  Generation  Languages  allow  easy  construction  of  screen-oriented  q)piications. 

•  Flmction  Points:  a  measure  of  the  functionality  of  stdtware  that  assigns  points  to  software  fimctions. 

•  LOC:  an  acronym  for  Line  Of  Code,  which  is  a  popular  measurement  Of  software. 

•  Metric:  software  measurement  in  general,  such  as  LCX^  or  Function  Points. 

•  Non-procedural  language:  a  computer  language  for  qxdlying  what  needs  to  be  done,  rather  than 
how  to  do  it  (30:213). 

•  SER:  Software  Enhancement  Request  is  a  request  for  software  siqjport  fiom  AFTT  freulty  and 
administrative  personnel  to  SCV. 

•  SQL*Fomis:  a  40L  that  defines  an  interactive  screen  conqirised  cf  trigger  aupa,  bkxta,  and  fields. 

•  SQL*Reports:  an  Oracle  database  access  langimge  to  retrieve  and  format  data  for  output. 

•  Work-hours:  the  houn  qtent  exclusively  on  die  software  support  project,  per  programmer. 
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•  Ikbks:  data  files  that  are  organized  into  crdumns  of  entity  attributes  and  rows  oi  entity  instances. 

•  llriggcr  steps:  a  SQL*Fonns  mechanism  to  validate  iiqiuts. 

•  Virtual  Machine:  a  computing  machine  that  could  be  inqrlemented  using  hardware  entirely,  but 
instead  simifie  hardware  operations  ate  used  by  software  to  provide  oonqriex  operations. 

L6  Definitions  for  Estimating 

•  ANOVA:  Analysis  of  variance. 

•  COCOMO:  an  acronym  for  Constructive  COst  MOdel  (6:58). 

•  Deleted  residuals:  a  measurement  of  the  i-th  residual  when  the  fitted  n^iession  is  based  on  the 
cases  excluding  the  i-th  one  (21:398). 

•  Indicator  variables:  quantify  a  qualitative  variaMe  for  inclusion  in  a  regression  model. 

•  Leverage:  a  measure  of  the  distance  between  the  values  of  a  given  observation  and  the  means  of 
the  values  of  the  independent  variable  for  all  obsovations;  it  is  used  for  outlier  detection  (21:395). 

•  LSBF:  Least  Squares  Best  Fit 

•  Randomness:  a  lack  of  a  systematic  pattern. 

•  Residual:  the  difference  between  the  dbsened  value  and  the  predicted  value. 

•  Specification:  the  extent  to  which  a  regression  model  is  appropriate  fior  the  data. 

•  SSE:  Error  sum  of  squares. 

•  SSR:  Regression  sum  of  squares. 

•  SSTX):  Total  sum  of  squares. 

•  Studentized  deleted  residualB:  a  deleted  residual  divided  by  its  estimated  standard  deviation 
(21:399). 

•  1>pe  I  error  deciding  to  reject  the  null  hypothesis  when  in  fact  it  is  valid. 

L7  Thesis  Orgardzation 

Chapter  One  provides  some  background,  de&ies  the  research  objective,  and  defines  some  termi¬ 
nology  relevant  to  this  thesis. 

Chapter  l>fro  reviews  current  literature  on  software  measurement  and  estinuiting.  The  review 
focuses  on  two  methods,  the  counting  of  lines  of  code  and  a  very  different  method  called  function  prtints. 
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Ccmi^exity  measures  and  other  metrics  are  also  reviewed,  as  well  as  software  cost  estimating  literature. 

C3uq;)tBr  Three  describes  the  software  siqjpoft  measurement  methodology.  The  three  strftware  siqiport 
measurements  that  are  collected  are  size,  effort,  and  schedule.  The  sizing  method  chosen  was  Marie  n 
function  points  mapiped  to  Oracle  database  software  components.  The  effort  is  measured  in  work-hours  and 
the  schedule  in  calendar-weeks.  Sttftware  was  written  to  collect  the  data  and  provide  sizing  by  analogy, 
using  data  dictionary  rqxxts. 

Chapter  Four  describes  the  software  stqtport  effort  and  schedule  estimating  mediodology.  The 
prediction  models  developed  are  based  on  regression  analysis  of  the  programming  teams’  effort  and  schedule 
response  to  software  support  requests  as  sized  by  Mark  n  function  points. 

Cluster  Five  presents  the  r^resskm  analysis  and  the  effort  and  schedule  models  for  one  and  two 
person  teams. 

Chapter  Six  contains  conclusions  from  the  research  and  recommendations. 
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n.  Literature  Review 


ILl  Overview 

Prediction  or  forecasting  of  any  kind  is  based  on  uqxits.  This  litentiire  review  focuses  primarily 
on  the  types  of  software  metrics  that  are  used  by  the  scrftware  indusiiy  as  inpnts  to  prediction  models. 
Hie  primary  software  metrics  reviewed  and  contrasted  are  lines  oi  code  and  function  pmnts.  Also,  several 
conqdexity  measures  are  discussed.  Different  environmental  Escton  that  rmqr  influence  the  software  support 
were  reviewed  as  well  as  existing  effort  and  schedule  estimating  models. 

ILl  Lines  of  Code  (LOCs) 

The  most  common  measure  of  software  size  is  lines  of  code.  Rakos  stales  that  all  software  project 
estimtting  methods  "are  crucially  dependent  upon  granularization:  breaking  things  into  small  pieces" 
(25:128).  Compared  to  a  typical  conqiuter  program,  an  individual  line  of  code  is  a  very  small  piece  of  the 
software.  Tb  understand  an  LCX:.  familiarity  with  the  concqn  of  a  virtual  machine  is  he^iifuL  Thnenbaum 
descrftes  different  levels  of  virtual  machines  that  exist  on  most  computer  systenu.  Each  level  has  a  code  or 
language  by  which  stdutions  to  a  problem  are  specified,  and  each  level  above  level  zero  can  be  translated 
into  lower  levels  (36:2-7). 

The  lowest  level  of  virtual  machines  is  the  level  zero,  the  digilal  logic  level.  At  this  lowest  level, 
strflware  is  executed  directly  in  the  electronic  drcuhs.  At  diis  low  level,  the  semantics  of  the  computer 
program  are  very  difficult  for  most  peo|8e  to  comptefaeod.  At  level  one,  the  microprogrsmmmg  kvd, 
a  code  is  used  to  describe  the  conqiuter’s  transitions  through  states  of  operation.  This  microprogram 
or  microcode  is  rqnesented  by  alphanumeric  characten  and  special  symbols.  This  levd  is  much  more 
comprehensible  than  level  zero,  but  it  is  still  cryptic  and  inconvenient  to  use.  At  level  two,  die  conventional 
machine  level,  multiple  microcode  satements  are  tqiesented  by  single  machine  code  statements.  TUs 
is  easiCT  to  work  widi  but  stOl  cumbersome.  Level  tlaee  is  the  opeiadng  system  iriiich  groq»  machine 
code  into  operathig  systnn  services.  It  is  not  ondl  level  fov,  the  assembly  language  level,  that  substantial 
applications  can  be  developed  by  a  prognmmer.  Most  programming  however  h  done  at  level  five,  die 
proUem-oriented  language  level.  At  this  level,  EngUsh-like  codes  are  used  to  qiecify  the  solution  to  the 
problem.  These  codes  are  disiriayed  in  V  ,  and  die  size  of  the  program  is  measured  in  terms  of  the 


number  of  lines  of  code,  or  LCX^  (36:2'-7). 


Hie  most  quoted  source  on  LOCs  is  Barry  Boefam  who  uses  the  term  'source  instruction’.  This 
term  includes  all  program  instructions  created  by  project  personnel  and  processed  into  machine  code  by 
some  combination  of  piqiocesson.  compilers,  and  assemblers.  It  excludes  comment  cards  and  urunodified 
utility  software.  It  includes  job  control  language,  format  statements,  and  datt  declaratioiis.  Instractkms 
ate  defined  as  lines  of  code  or  card  images.  Thus,  a  line  containing  two  or  mote  source  statements  counts 
as  one  instruction;  a  five-line  data  declaration  counts  as  five  instructioos  (6:59).  Boehm’s  is  only  one  d 
many  definitions  of  how  to  count  lines  of  code  after  the  code  has  been  written. 

Counting  lines  of  code  is  popular  because  qfier  the  code  has  been  written,  there  is  a  high  correlation 
between  LOCs  and  the  effort  that  produced  those  lines  code.  Butasizeestimaieneedstobeacconq>lished 
b^ore  the  lines  of  code  are  written.  Boehm  takes  it  for  granted  that  the  Mrftware  persotmel  can  make 
accurate  estimates  of  how  many  LOCs  will  be  written  to  strive  the  problem  at  hand,  but  warns  that 
underestimaies  can  hqipen  for  three  reasons.  *Rrst,  people  ate  basically  optimistic  and  desire  to  please. 
Second,  peofrie  tend  to  have  incomplete  recall  of  previous  experience.  Third,  people  me  generally  not 
familiar  with  the  entire  software  job"  (6:320-321).  In  addition  to  LOCs.  the  strilware  support  organization 
and  software  baseline  are  characterized  by  enviromnental  fhciors. 

Barry  Boehm  created  a  cost  estimating  tool  based  on  L(X^  called  the  Constructive  Cost  Model 
(COCOMO).  In  COCOMO,  environmental  facton  are  a  way  to  differentiate  the  unique  aqtects  of  different 
ptt^ts  and  envirorunents.  The  facton  excluded  fixxn  COCOMO  are:  type  of  qiplicatioo,  language 
level,  size  measures  other  than  lines  of  code,  requirements  vtriatility,  personnel  continuity,  managemem 
quality,  customer  interface  quality,  amount  of  documentatioo,  hardware  configuration,  security  and  privacy 
restrictions  (6:345-346,475).  The  Cacton  included  in  COCOMO  are  in  four  groiqrs: 

1.  produa  attributes  such  as  required  software  reliability,  dathbase  size,  and  product  oooqriexity; 

2.  computer  attributes  such  as  execution  time  constraiiMs,  main  storage  corntraints,  virtual  madiine 
volatility,  and  computer  turnaround  time; 

3.  personnel  attributes  such  as  analyst  captrirility,  appUcations  experience,  progmuner  capability, 
virtual  machine  eaqierience,  and  programming  language  experience; 

4.  project  attributes  such  as  modem  programming  practices,  use  of  software  tools,  and  required 
development  schedule.  (6:345-346,475) 


7 


Tbe  analyst  piavides  iqNits  to  CXXX)MO  by  diaiactciizing  the  enviromiental  facton  on  various 
scales  and  by  eatimating  how  ntany  LOCs  will  eventually  be  produced.  Then  CXXX)MO  estimates  the 
effort  and  schedule  of  the  project  based  on  the  analyst’s  iiqiuts.  However,  the  use  of  LOCs  as  a  unit  of 
software  measure  is  the  subject  ttf  much  criticism. 

Capen  Jones  points  out  the  critical  inqnrtance  that  measurement  has  contributed  to  die  progress  of 
science  in  general  and  then  says  that  scrfitware  measurement  is  probhUy  the  most  deficiem  aspea  of  die 
field  of  software  engineering.  He  is  not  saying  that  in  the  last  3S  yean  of  conqwter  history  no  one  has 
tried  to  measure  stdtware,  rather  he  is  saying  that  the  accqned  measnrementt  are  not  measuring  what  they 
purport  to  measure.  He  qiecificaOy  criticues  the  LOC  measurement  for  creating  paradoxical  infionnation 
and  he  lists  three  problems  (18:49). 

First,  there  has  never  been  a  national  or  international  standard  for  a  L(X!  that  encompasses  all 
procedural  languages.  Some  line  counts  are  defined  by  physical  carriage  returns,  while  odien  are  defined 
logically  by  delimiters  such  as  a  semicolon.  The  line  of  code  counts  can  contain  one,  some  or  aD  of  die 
following:  executable  statements,  data  definidons,  comments,  and  Mank  lines.  There  is  little  agreement 
on  how  many  times  reused  code  should  be  counted:  once,  each  time  it  is  reused,  or  never.  Tbere’s  even 
more  problems  when  different  computer  languages  are  mixed  to  together,  and  how  to  count  additions, 
changes,  and  deletions  (18:49). 

Second,  software  can  be  produced  by  such  methods  as  program  genetaion,  qaeadsheets,  graphic 
icons,  reusable  modules  of  unknown  size,  and  inheritance,  wherein  entities  such  as  lines  of  code  are 
totally  irrelevant  (18:49).  This  is  eqiecially  true  of  the  4GL  S(^*Fonns,  where  software  is  developed  by 
interacting  with  the  appUcations  generation  screen.  Source  lines  of  code  are  produced  by  the  applications 
generator,  but  it  is  not  necessary  to  look  at  them  to  complete  a  project  So  if  the  programmer  chooses  not 
to  ever  look  at  them,  for  practical  purposes  they  do  not  exist 

Third,  LOC  metrics  paradoxicaOy  move  backwards  as  the  level  of  the  language  gets  higiier,  so  that 
the  most  powerful  and  advanced  languages  appear  to  be  less  productive  than  the  more  primitive  low-level 
iflngiiajjM  (18:49).  Tb  understand  the  productivity  paradox,  recall  the  concqit  of  virtual  machmes.  When 
a  higher  level  machine  groups  together  many  instructfons  of  a  lower  level  madiine,  then  that  higher  level 
instruction  does  the  work  of  many  lower  level  instructions  bitt  only  counts  as  one  LOC  For  raamfde,  if  a 
programmer  using  a  lower  level  languages  creates  KXX)  LOCs  to  solve  a  proUem  and  another  programmer 
using  a  highCT  level  language  solves  the  same  problem  with  only  100  LOCs,  then  Iqr  LOC  count  the 
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fint  prognmmer  is  considoed  to  lave  K^ed  a  pioblein  ten  times  laiger  than  the  other  programmer. 
When  a  fixed  number  of  functions  is  delivered  with  increasing  nund)ers  of  LOGS,  productivity  drops  when 
measured  in  terms  of  functions  per  LOG.  as  dtfictti  in  Figure  1: 

Pnductivity 


Figure  1.  Productivity  Paradox 

Gounting  LOGs  also  leads  to  a  quality  paradox  because  high-quality  programs  are  usually  more 
succinct  than  programs  that  are  hastily  developed  in  an  ad  hoc  manner.  If  the  more  suodna  programs 
have  fewer  LOGs  than  the  lower  quality  programs,  an  equal  number  of  enoti  results  in  a  higher  error  per 
LOG  ratio  than  the  lower  quality  program.  In  fact,  if  a  lower  quality  program  had  five  times  as  many 
LOGs  than  the  more  succina  program,  then  one  error  in  the  high  quality  program  would  have  an  error 
per  LOG  ratio  equal  to  the  lower  quality  program  with  five  errors.  In  other  words,  if  these  two  programs 
are  offered  lo  satisfy  the  same  requirement,  where  one  has  five  enon  while  the  other  has  one  error,  then 
by  using  erron  per  LOG,  they  are  deemed  to  be  trf  equal  quality.  Hiese  paradoxes  exist  because  the 
premise  of  using  LOGs  as  a  measure  ci  software  is  fiiat  the  LOGs  ihemsehes  are  the  soiutioo  to  a  software 
requirement,  rather  than  the  fimctionaUty  of  the  software. 

n  J  Albrecht’s  Function  Paints 

Function  points  are  firndamentaDy  different  than  lines  of  code.  The  premise  of  fimction  poim 
analysis  is  to  measure  the  toitwmt  fimctionality  delivered  to  die  user.  The  term  ’ftmrtionaBqf*  shifts  the 
emphasis  away  from  how  die  LOGs  implement  the  software,  and  instead  emphasize  what  the  software 
does.  Fbr  exanqde,  if  a  payroll  program  is  supposed  to  prompt  the  user  for  a  social  secarky  number,  locale 
that  number  in  an  etiqdoyee  record,  and  then  diqili^  that  employee’s  aid«f-moath  pay,  then  the  program 
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pafofms  three  functioas:  recdves  input,  processes  a  recocd.  and  outputs  the  results.  When  counting 
functionality  in  this  way.  the  LOCs  used  to  implement  the  software  are  inelevant.  and  the  focus  is  on 
the  strftwve  behavior.  Continuing  with  the  payroll  exanq>le.  if  10  programmers  developed  scrftware  to 
perform  the  same  payroll  functions,  there  would  be  10  different  LOC  counts  due  to  individual  differences 
and  the  inherent  variety  associated  with  alteniate  strftware  scdutioos.  However,  the  number  of  functions 
provided  by  those  10  programmers  would  be  identicaL  The  software  is  the  result  of  a  request  by  the  user 
to  perform  these  functions,  and  function  pmnts  ve  a  measurement  of  the  functianality  required  by.  and 
valued  by  the  user  of  the  srrftware.  Allan  Albrecht,  an  IBM  researcher,  introduced  a  means  of  quantifying 
software  functionality  by  assigning  points  to  five  categories  of  functions  based  on  their  value  to  the  user. 
Ibble  1  introduces  the  categories  of  function  points. 


Ibbk  1 

Fnnctioa  Count  (FC) 


lype 

Description 

Simple 

Average 

Complex 

IT 

External  Input 

x3 

x4 

x6 

OT 

External  Ouqxit 

x4 

x5 

x7 

FT 

Logical  Internal  File 

x7 

xlO 

xl5 

El 

External  Interface  File 

xS 

x7 

xlO 

QT 

Extenud  Inquiry 

x3 

x4 

x6 

•  Oiupitfs  are  items  of  business  information  processed  by  the  conqmler  for  the  end  user. 

•  Inquiries  are  direct  inquiries  into  a  database  or  master  file  that  look  for  qwcific  data, 
use  simple  keys,  require  immediate  response,  and  perform  no  update  ftmctioos. 

•  Inputs  are  items  of  business  data  sent  by  die  user  to  the  conqwier  for  processing  and 
to  add.  diange,  or  delete  something. 

•  Files  are  data  stored  for  an  tqjffiication,  as  logically  viewed  by  the  user. 

•  Interfaces  ate  data  stored  elsewhere  by  another  qiplication  but  used  by  the  one  under  « 

evaluation.  (12:5) 

Since  Albrecht  uses  the  ftmctiooal  value  of  the  software  as  determined  by  the  user  as  a  guideline  for 
subjecdvdy  identifying  function  points,  there  are  significant  ambiguities,  lb  reduce  amtfiguities  associated 
with  assignii^  function  points,  Brian  Dr^er  dedicated  an  entire  book  to  enumerating  roles  for  asrfgning 
function  poinu.  lb  identify  ouqMts,  Dr^  nys  "count  each  unique  data  or  contrd  output  ptocedutally 
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generated  that  leaves  the  qiplication  boundaiy”  (12:10).  lb  kfentily  iqHits,  "count  eadi  unique  user  data 
or  control  input  that  enten  the  application  boundary  and  also  updates  (adds  to,  changes,  or  deletes  Cram) 
a  logical  internal  file,  data  set,  table,  or  independent  data  item”  (12:16).  Iiqwts  and  ouqxits  are  considered 
unique  in  so  far  as  they  have  (UfTetent  fiinnats  or  require  (fifferant  processing  logic.  Since  the  function 
point  analysis  is  indqtendent  of  any  language,  the  measurement  avoids  the  distiacting  and  paradoxical 
details  of  lines  of  code  (1:1).  There  are  three  stqM  in  detennining  function  points. 

Rnt,  it  is  necessary  to  classify  and  count  the  five  user  function  types  delivered  by  die  development 
pre^L  Hieae  are  external  input,  external  outputs,  internal  file  types,  interfile  file  types,  and  inquiry 
types.  Each  of  the  functions  that  are  assigned  to  one  of  die  five  cai^ories  is  further  classified  as:  complex, 
average,  or  simple.  The  weights  in  Ihble  1  show  how  the  total  unadjusted  function  count  (PC)  is  conqnited. 

The  second  step  is  to  calciilatf.  the  processing  conqilexity  (PC)  1^  ranking  14  environmental  factors 
according  to  degree  of  influence  on  a  scale  from  zero  to  five.  The  factors  are:  data  communications, 
distributed  data  or  processing,  performance  objectives,  heavily-used  configuration,  transaction  rate,  on-line 
data  entry,  end  user  efficiency,  on-line  iqidate,  complex  processing,  reusability,  conversion  and  installation 
ease,  operational  ease,  mult^le-site  use,  and  facility  clumge  (2:640).  The  processing  complexity  adjustment 
(PCA)  is: 


PCA  =  0.65 +  (0.01  ♦PC) 


0) 


Third,  the  delivered  function  points  (FP)  are  calculated  by  multiplying  the  unadjusted  function 
points  tiroes  the  adjustment  factors  (12:71): 

FP=FC*PCA  (2) 

Jones  notes  that  after  ten  yean  of  use,  ”die  cuireitt  national  average  for  software  productivity  at  the 
project  level  in  the  United  States  sppean  to  be  about  five  ftmetion  prants  per  staff-month"  (18:11).  lUdng 
into  account  all  the  staff-months  of  an  entire  stdlware  development  corporation  and  die  function  points 
delivered,  Jones  says  a  strategic  or  corporate  productivity  measurement  averages  1.5  function  pennts  per 
staff-month.  These  numben  are  for  all  types  of  projects  and  Jones  notes  that  for  management  information 
systems  (such  as  SCV’s  system),  the  productiviQr  is  hi^ier  than  average  at  about  eight  function  points  per 
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staff-monlh.  Jones  also  says  that  a  maintenance  programmer  can  take  on  siqiport  of  a  baseline  ranging 
from  SOO  to  ISOO  function  points,  dqtending  on  die  structuredness  of  die  design  (18:81,147). 

Chaiies  Behrens  studied  25  development  projects  in  the  data  processing  organization  of  a  large 
financial  institution.  He  chose  an  hour  as  the  unit  of  time  and  then  ratmiati<<i  ifae  output  in  fimction  points 
per  hour  and  also  the  unit  cost  in  hours  per  function  point.  In  1980, 11  projects  ranged  in  size  finom  27  to 
599  function  pmnts  and  from  600  to  28,700  hours.  Productivity  measures  tanged  from  9.7  to  47.9  boon 
per  fimction  pmnL  Hie  mean  was  183  houn  per  fimction  prfinL  In  1981, 14  projects  tanged  in  size  from 
22  to  435  fimction  points  and  85  to  10,600  houn.  Productivity  measures  tanged  from  2.1  to  23.4  boon 
per  fimction  point  with  a  mean  of  9.4  (4:649).  The  interesting  effect  revealed  in  Bduens’  research  is  that 
when  unit  costs  are  plooed  against  function  points,  the  line  of  best  fit  is  curving  iqrward.  The  interpretation 
is  that  "as  projects  become  larger,  their  unit  costs  become  higher  as  shown  in  Rgure  2,  suggesting  that 
everything  else  being  equal,  small  projects  are  mote  productive  than  large  projects"  (4:649). 


Figure  2.  Behren’s  Reaeardi 


Darlene  Brown  described  methods  of  catenlating  productivity  jsing  fuKtion  pnnts  and  included 
maintenance  activities.  She  chose  a  labor-month  as  the  unit  of  time  and  calcnlamd  the  ratio  of  function 
points  delivered  to  the  number  of  labor-months.  She  divided  maintenance  into  two  groiqx,  enhancement 
activities  and  siqjpott  activities.  Hie  difference  between  the  two  is  that  enhancement  changes  tiie  functions 
while  stqiport  does  not  change  the  functions  but  ^on  is  spent  to  satisfy  some  user  need.  The  measure  for 
enhancemem  productivity  is  the  change  rate  and  for  siqipoit  is  the  snppon  rate  (8:27-28).  Darleae  Brown 
discusses  the  use  of  productivity  rates  as  a  means  of  predicting  future  work  efforts.  She  distingoishes 
fotecastt  by  new  development,  enhancement,  and  sigrport  For  each  case  she  says  that  after  die  analyst 
has  determined  the  number  of  function  points  that  will  be  devdoped,  enhanced,  or  supporaed,  a  sinqiie 
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mullipUcatioa  ot  the  qjfiropriate  late  liines  the  funetkn  points  will  give  the  number  of  labor  months  to 
do  the  job  (8:30). 

Several  authors  advocate  that  software  metrics  and  estimation  techniques  should  be  tailored  for 
a  specific  site.  Ian  Sommerville  states  that  ”the  parameters  assodaied  with  diCEerent  modeb  are  highly 
otganizaikmal  dqiendent"  (31:516).  Tom  DeMarco  offers  the  insight  that,  "strftware  metrics  cannot  be 
treated  as  off-the-shelf  products,  and  that  organi/ations  that  adqn  techniques  and  measures  for  their  own 
use  always  seem  to  come  out  ahead"  (10:160).  Bryan  Ratcliff  and  Anthony  RoUo  say  that  due  to  an 
organization’s  development  paradigm  function  point  analysb  "will  require  substantial  tailoring  to  fit  an 
operational  development  framework"  (26:80).  Mtchiel  van  Oennehten  conducted  a  survey  of  software 
engineers  opinions  as  to  why  software  projects  are  delayed  and  found  that  "the  reasons  were  specific  to 
the  engineering  environment  in  question  because  of  differences  among  the  software  engineets,  the  type  of 
software  developed,  and  the  organization  of  the  department"  (37:585). 

June  Vaner  and  Graham  Thte  describe  a  case  study  for  a  development  project  that  used  a  4GL 
called  ALL.  The  goal  was  to  quickly  build  an  information  system  for  a  correspondence  schooL  They 
used  function  point  analysb  to  estitnate  the  size  of  the  project,  then  they  converted  the  function  poinb 
to  CX>BOL  and  adjusted  for  die  presumed  benefit  of  using  a  4QL.  They  underesiimaied  actual  effort  by 
23  percent,  but  underestimated  the  schedule  by  only  3  percent  (38:15-22).  The  tesuUs  suggest  that  the 
analysb  had  a  consbtent  measure  tff  strftware  size  using  fiinctioo  poinb  before  the  code  development. 

Graham  Low  and  Ross  Jefery  rqwrt  that  their  studies  indicaie  that  "functioa  poinb  appear  lo  be  a 
more  consbtent  a  priori  measure  of  system  size  than  lines  of  code"  (19:71).  Low  and  Jefery  rqiort  the 
resulb  of  an  empirical  research  projea  into  the  consbtency  and  limitations  (ff  fiinctioo  pranb  as  an  a  priori 
measure  of  system  size  compared  to  the  traditional  lines  of  code  measure  (19:64).  They  discuss  some  lines 
of  code  (LCX:)  attributes  and  variations  and  then  stale  that  using  LOCa  requites  an  "a  priori  estimaie  of 
system  size  based  on  past  experience  of  the  person  performing  the  estimate  with  similar  projecb  and/or 
systems"  (19:64).  The  researchen  go  on  to  say  duu  to  the  best  of  their  knowledge  "the  consistency  of 
LOCs  as  an  a  priori  measure  of  system  size  has  not  been  tested"  (19:64). 

The  coneqx  of  counting  function  poinb  has  been  studied  extensively,  but  not  without  criticism. 
Boehm  notes  that  function  pohib  suffer  in  terms  tff  clarity  and  objectivity  (6:482).  Charles  Symons 
analyzed  the  use  of  function  poinb  on  some  bage  prqjecb  and  reported  some  problems  with  ambiguity. 
He  devised  a  new  approach  called  Mark  n  function  poinb  (32:5). 


II.4  SymoBS’  Mark  n  Fuoctiao  Points 


Symons  thinks  that  Albrecht’s  components  ate  difficult  to  identify  in  a  relational  database  envi¬ 
ronment,  and  difficult  to  intmpret  for  on-line  interactive  transactions  on  the  same  screen.  He  questions 
how  Albrecht  arrived  at  the  weights  and  levels  of  complexity  when  counting  unadjusted  function  points. 
Symons  does  not  diink  that  the  list  of  14  environmemal  factors  is  exhaustive  and  that  each  of  them  should 
not  carry  the  same  degrees  of  influence.  Also,  he  criticizes  the  lack  of  a  measure  of  die  internal  processing 
complexity  and  the  treatment  of  system  components  as  discrete  rather  than  integrated  (33:18-22). 

Symons  has  augm^ted  the  function  point  concqx  and  calls  it  Mark  n  function  points.  It  is  based 
(Ml  a  similar  premise  of  measuring  functionality  as  Albrecht’s  function  points,  excqx  that  Symons’  method 
is  more  oriented  towards  development  ^ort,  than  user  value.  Instead  of  five  categories,  Symons  has  three: 
inputs,  entities,  and  outputs.  The  input  and  (mqxit  categories  also  include  Albrecht’s  interface  cai^ory. 
For  the  new  entity  category,  he  tq^Iies  entity-ielationship  analysis.  For  the  purpose  of  counting  function 
points,  entities  can  be  thought  of  as  a  ccMnlniiatioo  (A  Albrecht’s  files  and  inquiries. 

Identifying  the  comiriexity  of  each  component  is  addressed  by  "counting  the  number  of  entity-types 
referenced  by  the  transaction-type"  (32:S).  Referenced  means  created,  updated,  read,  or  ddeted.  The  entity 
model  in  Figure  3  shows  how  entity  types  relate  to  each  other  and  the  lines  with  three  prongs  at  one  end 
indicate  a  (Nie-to-many  relatkMish^  between  entities,  (for  example,  a  single  customer  on  be  associated 
with  many  orders). 


Figure  3.  Entity  Modd  (33:26) 
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Symons’  ’transaction’  constnict,  is  "a  unique  iiqmi^pfocess/oidput  combination  triggered  by  a  unique 
event  of  interest  to  the  user,  or  need  to  retrieve  information'’  (33:23).  IhUe  2  shows  an  example  of  function 
points  counts  by  transaction.  Based  on  the  tabulatkxis  of  iiq»ts,  outputs,  and  entities,  the  Mark  n  formula 


Ibble  2 


Uiia4jiisted  FuBCtkiB  Point  Count  Example  (33:26) 


TOANSACnCW 

INPUTS 

ENTITIES 

OUTPUTS 

Add  Customer 

53 

1 

3 

Inquire  Stock 

2 

3 

10 

Add  Order  Head 

20 

2 

12 

Add  Order  Item 

6 

5 

6 

Inquire  Quantity 

2 

4 

4 

Rqxxt  Stock 

1 

3 

21 

TOTAL 

84 

18 

56 

for  information  processing  size  in  unadjusted  function  points  is: 

UFP  =  Wi  xNi  +  WexNb-\-Wo^  No,  where  (3) 


•  N]  s  the  number  of  input  data  element  types, 

•  Wi  s  weighi  of  an  input  data  element  type, 

•  Ne  s  number  of  entity-type  references, 

•  We  s  weight  of  an  entity-type  reference, 

•  No  s  number  output  data  elernem  types, 

•  Wo  s  weight  of  an  output  data  element  type,  and 

•  Ni,  Ne,  and  No  are  each  summed  over  all  tramacdon-types  (33:30). 

Symons  added  five  environmental  Eacton  to  Albrecht’s  14.  Tbe  additional  five  £■;«»  are  the  needs: 

to  interface  with  other  qtplications,  for  special  security  features,  to  provide  direct  access  for  third  patties, 
for  documentation  requirements,  and  for  special  user  training  facilities,  such  as  a  training  subsystem. 
(32:7).  Hiese  additional  five  factors  added  to  Albrecht’s  14  create  a  total  of  19  factors.  An  additional  20th 
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ficior  emaged  later,  as  the  need  to  define,  select,  and  install  special  hantware  or  software  oniqudy  for  the 
qtplication  (32:7).  Sytnons  calls  these  factors  the  degrees  of  influence  (DI). 

After  analyzing  32  systems,  Symons  obtained  weights  which  he  calls  the  'Industry  Average  Set’: 
WiaO^S,  We«1.66,  Wo^26  (33:30).  The  resulting  unadjusted  functioa  points  (UFI^  formula  is: 

UFP  =  0.56xNi  +  iMxNB  +  0.26xNo  (4) 

The  fiuiction  point  (PP)  count  is  adjusted  by  die  sum  of  the  d^rees  of  influence  in  the  technical  cooqdenty 
adjustment  (TCA)  (33:80): 


TCA  =  0.65  -1-  0.005  x^DI 

(5) 

FP  =  UFP  X  TCA 

(6) 

Capers  Jones  has  praise  and  criticism  to  the  Maik  D  Function  Points  defined  by  Symons.  Jones 
thinks  that  Symons’  idea  of  counting  entities  and  relationships  adds  a  new  dimension  of  rigor  to  fimetion 
point  counting.  However,  he  also  thinks  that  Symons’  shift  away  from  Altaecht’s  user  value  basis  to  a 
development  effort  basis  is  a  step  backwards.  Jones  also  says  that  Mark  n  Ftinction  Points  can  result  in 
counts  that  are  up  to  30%  higher  than  Albrecla’s  function  points  (18:97). 

II.5  Jones’  Feature  Points 

A  technique  called  feature  points  was  created  Capers  Jones.  He  supplements  fimetion  ptnnts 
as  defined  by  Albrecht  with  a  sixth  parameter  to  real-time  and  systems  software,  by  categorizing  the 
complexity  of  the  algorithms  (18:9).  Ihere  ate  many  definiiions  of  algorithms,  but  for  the  purpose  of 
counting,  Jones  states  that  "an  algorithm  is  a  bounded  computational  proUem  which  is  included  widiin  a 
specific  computer  program”  (18:84).  He  also  says  die  process  of  assignirtg  the  oonqdexity  of  algorithms 
is  ad  hoc  and  is  in  need  of  a  rigorous  taxonomy. 

The  new  algorithmic  parameter  is  assigned  a  wei^t  tanging  from  one  to  ten  with  a  default  weight 
of  three.  Also,  the  weight  for  logical  data  files  from  AOxecht’s  avenge  value  tff  ten  is  reduced  to  seven, 
reflecting  the  lesser  significance  of  logical  files  to  systems  stdtware.  Including  algorithmic  considerations 
generates  higher  feature  point  counts  for  systems  software  than  to  NOS  stdtware.  Symons  praises  Jones  to 
introducing  a  measure  of  algorithmic  complexity,  but  warm  that  it  is  difficult  to  establish  standard  cat^orks 
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of  algorithms:  ”Miich  woric  has  been  done  to  intfoduce  measures  for  the  oonqtlexity  of  algorithms,  but 
the  data  to  measure  their  'size'  are  not  generally  availri>le  eariy  in  the  system  life  in  a  fonn  suitable  for 
a  function  point  metric''  (33:42). 

IL6  Halstead's  Software  Sdeaoe 


An  assembly  language  programmer  named  Mmirice  Halstead  developed  a  metric  he  called  software 
science.  He  wanted  to  count  the  number  (tf  errors,  the  ^ott  to  understand  a  program,  and  the  effort  to 
encode  a  program  (3:1-2).  He  based  his  counts  on  operators  and  operands.  Rrst,  size  is  conqxited: 

•  m  «  unique  operators, 

•  02  «  unique  operands, 

•  n  B  ni  +  02, 

•  Ni  «  total  (iterators, 

•  N2  s  total  operands, 

•  size  N  »  Ni  +  N2. 

Halstead  then  used  this  size  computation  to  develop  a  formula  for  the  volume,  V,  which  characterizes 
the  encoding  necessary  for  a  paiticular  prognnt.  He  also  defined  potential  volume,  V*,  as  the  minimum 
encoding  of  a  program,  but  he  offered  no  formula  for  V*  (3:1-2). 


V  =  N  X  k)g2  n 


C7) 


He  used  V  and  V*  to  characterize  die  level  of  abstraction  of  a  program,  L,  but  since  the  value  V*  is  not 
available,  an  iqiproximation  fiir  L  was  devised: 


L 


2  na 


(8) 


Halstead  also  characterized  the  effort,  E,  to  understand  a  program  as  the  number  of  'dementary  mental 
discriminations'  divided  by  the  level  of  abstraction,  inqilying  that  the  more  abstract  the  program,  the  easier 
it  was  to  understand: 


E  =  etlin«ea  b,  £  =  S 

L  L  L 


(9) 


Based  on  an  article  by  a  psychologist  that  said  humans  process  between  five  and  22  dementary  mental 
discriminations  per  second,  Halstead's  experimenu  seemed  to  confirm  that  hypothesis  widi  a  value  of  18. 
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Consequently,  he  used  the  value  to  compute  the  time,  T,  to  encode  a  program: 


T  = 


£ 

16 


(10) 


IL7  McCabe’s  Cydoautk  Compleiity 

Thomas  MoChbe  devised  a  measurement,  v(G).  for  characterizing  die  difficulty  of  testing  totamt 
and  it  is  called  ’cyclomatic  complexity’: 


v(G)  =  e  —  n  +  2p  (11) 

The  letter  G  is  a  graph  representing  the  padis  of  flow  in  a  program,  e  is  the  number  of  edges  in  the 
gnqih,  n  is  the  number  of  nodes,  and  p  is  the  number  of  fully  connected  components  (20:308).  A  rule  of 
thumb  is  that  a  cyckxnatic  number  greater  than  10  characterizes  a  program  that  will  be  difficult  to  test 
However,  ’case’  statements  tend  to  drive  up  the  cyclomadc  number,  and  they  are  subjecdvdy  considered 
an  abstraction  that  makes  programs  easier  to  understand  (aid  therefore  easier  to  test).  Deqnie  the  apparent 
simplifying  effect  of  case  statements,  they  create  many  paths  that  require  consideiation  for  testing  purposes, 
and  so  the  high  cydomatic  number  does  characterize  that  testing  problem. 

IL8  Other  Sizing  Methods 

There  are  a  variety  of  other  measures  of  software.  Henry  and  Lewis  present  "an  experiment 
that  introduces  a  non-destructive  method  for  imitating  metrics  into  a  large-scale  commercial  software 
developmeot  environment"  (16:89).  They  discoss  three  categories  of  metrics:  code,  structwe,  and  hybrid 
metrics.  Code  mdrics  typicaDy  measure  the  source  code  instruction  widiin  a  smgle  module  and  have 
limiiBd  value  for  the  total  software  system.  "Structure  metrics  concentiate  on  the  overall  structure  of  a 
software  system  by  evaluating  the  inter-connectivity  among  procedures"  (16:90).  Henry  and  Lewis  used 
structure  metrics  called  Kafura’s  infonnttioa  flow  and  Belady’s  cluster  metric. 

Henry  and  Kafiita  characterized  the  complexity  of  an  entire  system  of  intencting  modules 
(15:510-518).  They  count  the  flows  into  and  out  of  a  module  at  fon-int  and  Cn-oitis.  The  informa¬ 
tion  flow  (IF)  metric  is  based  on  the  fon-in  and  fonout  of  the  modules,  and  the  length  ai  the  module  which 
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is  some  cooqdexity  metric  of  the  measurer’s  choice.  The  infonnatioo  flow  (IF)  is: 

IPi4ength  x  (fmin  x  Cmout)  (12) 

Henry  nd  Lewis  also  discnssed  hybrid  metrics  which  are  code  and  stmctnre  metrics  combined.  They 
can  the  hean  of  their  structure  metrics  the  communication  database  because  it  "identifies  communication 
lines  among  modules"  (16:90).  This  is  similar  to  a  data  dictiooary.  Iheir  commaiication  database  is  "used 
to  infionn  a  system  developer  of  the  proper  order  in  which  to  rdNiiki  the  conyonems  of  a  system,  baaed 
on  the  use  of  qiecific  modules  by  other  modules"  (16:91).  This  is  critical  infonnatioo  for  estimating  the 
scope  and  effort  of  a  woric  order,  hecaiiie  a  change  to  one  module  may  require  a  change  to  other  modules 
that  use  the  first  one  being  changed. 

Another  aggr^ate  metric  is  measured  acrou  time.  Henk  Blaiiken  discusses  "query  processing  in  a 
database  management  system  (DBMS)  that  has  comfriete  control  over  versiooed  complex  objects"  (5:1). 
These  objects  are  called  complex  because  in  addition  to  the  complex  relationships  between  data  stnichires. 
complex  ot^ts  record  a  history  of  the  changes  to  die  object  Prom  the  point  of  view  of  someone  svho 
nuuiages  the  software  configuration  of  modules,  such  a  databnse  could  store  source  code  and  the  history 
of  changes  to  it  Blanken  discusses  what  he  calls  *as-of>queries’  and  ’waik-throo^<tiine’  queries  (5:2). 
An  as-of-query  retrieves  inftxmation  that  was  current  as  a  certain  time  and  date.  Hie  more  relevant 
query  for  this  literature  review  is  the  walk-diroo^-tiine  (WTT)  query.  He  stales  that  a  WTT  query  could 
be  constructed  "by  generating  an  as-<rf  query  for  each  moment  of  change"  (5:2). 

II.9  Eatinating  Effort  and  Schedule 

Software  cost  estimating  models  have  a  tqmtatioo  of  being  inaccuiate.  Boehm  rales  a  software  coat 
estimation  model  as  good  if  it  is  within  20  percent  of  actual  coats  70  percent  of  the  time,  within  classea 
of  projects  that  were  used  lo  calibrate  the  model  (6:3^.  Ihe  predktiooa  are  bated  primnily  on  the  size 
of  die  project,  doqg  with  a  variety  of  other  firetoa.  John  Rakos  states  that  "there  are  only  two  focton  that 
affea  the  duration  of  a  task:  die  oonqilexity  of  the  task  and  the  productiviqr  of  the  pecMonel  perfonning 
it"  (25:132).  Most  models  Uke  COCX)MO  allow  a  peraomel  focior  to  be  characterized  and  submitted  as 
input  to  the  model  Considering  die  intetpertonal  dynamics  involved  in  sidtware  developmeai,  a  team  of 
programmers  can  have  a  perfonnanoe  reqxnse  different  ftom  another  team,  so  it  seems  reaaoirtble  Cor  an 


19 


organization  Oat  is  tailoring  its  own  model,  to  track  the  perfotnmce  of  qKcific  teams  as  if  they  were 
individuals.  Humphrey  iqnrts  a  method  for  projecting  software  productivity  by  collecting  datt  for  qwcific 
individuals  or  for  a  specific  group  individuals  working  together  as  a  team.  He  also  pmnts  out  that 
individuals’  productivity  follows  the  individual’s  learning  curve,  and  so  successive  developmett  times  are 
autocorrelated.  He  cautions  tiiat  the  orilected  data  is  unique  to  an  individual  or  team: 

It  should  be  emphasized,  however,  tiiat  if  tite  database  concerns  the  productivity  experience 
of  one  programma.  the  projected  productiviq^  values  are  only  valid  for  that  individual.  If 
tew"  projections  are  desired,  relevant  team  experience  data  should  be  used  (17:196). 

Lawrence  Putnam  defined  methodttiogies  for  estimating  effort  and  schedule  for  software  projects 
with  different  numbos  of  programmers.  He  describes  small,  and  medium  to  large  projects,  with  medium 
projects  having  four  or  more  people.  Putnam  says  that  there  is  enough  similarity  in  the  groiqi  problem¬ 
solving  process  that  groups  of  four  or  more  pet^e  tend  to  have  similar  problem  solving  responses  r^ardless 
of  team  composition.  However,  for  a  small  groig)  of  one,  two,  or  three  people,  there  is  greater  variation 
in  problem  solving  response  from  group  to  group  due  to  individual  differences  (24:216). 

n.lO  Summary 

The  quality  of  a  prediction  can  be  no  better  than  the  quality  of  the  inputs  to  the  prediction  process. 
Existing  software  effort  estimation  models  use  size  as  the  primary  input  This  review  focused  on  strftware 
size  measurements  such  as  lines  of  code  and  function  pmnts.  The  essential  difference  between  LOCs 
and  function  points  is  that  LOCs  measure  the  solution  to  a  software  requirement,  while  fimction  points 
measure  the  functionality  in  the  requirement  itsdf  regardless  of  how  many  L(X^  were  created.  Other 
pcqxilar  sizing  methods  focus  more  toward  measuring  the  conqilexity  of  software  based  on  some  form  of 
sctitware  unit  interrelationships. 

In  addition  to  size,  many  environmental  facton  are  quantified  as  inputt  to  effort  eatimation  models. 
These  facton  are  intended  to  characterize  the  uniqueness  of  a  given  acrftware  organization  for  software 
cost  estimating  tools  intended  for  industry  wide  use.  Rnally,  caae  studies  were  reviewed  that  explored  the 
problem  of  establishing  programmer  productivity  and  predicting  project  duration. 
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nL  Meanrement  Methodology 


nLl  Overview 

Data  collection  methods  were  developed  to  satisfy  die  research  objective:  to  estimate  the  expected 
stqjport  effort  sod  schedule  given  the  size  of  an  Oracle  database  strftware  support  request  This  chapter 
addresses  the  investigative  questions  idaied  to  software  sqipon  sizing,  effort,  and  schedule  measurement: 

•  What  is  the  most  meaningful  software  size  measure? 

•  How  much  effort  and  schedule  are  required  for  given  leveb  of  sqiport? 

The  guiding  principles  for  selecting  a  meanmgfiil  sizing  method  is  to  collea  data  in  a  way  that  is: 

1.  unambiguoas  and 

2.  easily  estimated  before  the  project  b^ins. 

In  Chapter  IVo,  Rakos  noted  that  software  project  estimathig  dqiends  upon  breaking  software  into 
small  pieces,  but  if  the  pieces  are  too  small  the  project  staff  could  qiend  an  inordinate  amount  of  time 
trying  to  identify  every  last  piece.  The  benefit  ci  fine  granularity  should  not  come  at  a  cost  that  is  a  large 
proportion  of  the  project  itself.  Consequently,  there  is  a  trade-off  between  having  less  ambiguify  in  die 
siziiig  definition  at  the  same  time  as  easy  estimation  befiare  the  projea  begins. 

DU  Software  Unit  of  Measure 

Oracle  SQL*Fotms  and  S(^*Repottt  have  hltle  if  any  algorithmic  conqdexify,  and  consequendy  all 
of  the  various  conqilexity  metrics  are  of  little  use.  Since  S(^*FDrms  and  S(H'*Keports  are  rqxesenied  by 
source  lines  of  code,  a  look  atLOC  coontiag  was  warranted.  Upon  closer  examination  LOCs  are  not  very 
meaningfuL  Hrst,  they  are  very  ambiguous  as  highlighted  by  Capers  Jones,  and  Barry  Boehm  even  says 
that,  "source  instructioos  are  not  a  unifatm  commodity,  nor  are  they  the  essence  of  die  desired  product" 
(6:32).  In  fact,  they  are  even  kn  meaningful  in  the  case  of  S(^*Fotms,  becaine  the  LCX^  are  normally 
generated  and  possibly  unseen  by  die  programmer.  The  literatnre  indicaies  that,  befiote  the  pre^ 
begins,  it  is  easier  to  esdmaie  function  points  than  LOCs  (19:1).  Hie  dose  aisoriatinn  of  ftmetion  points 
with  the  ftntctionality  required  of  the  software  increased  itt  appeal  as  an  independent  variable  cfaaracierizing 
software  size.  However,  the  ambignoos  aepaaHoa  of  inquiries  ml  hiietfaoes  ftem  hqiuis  and  ooqmis  as 
defined  by  Albrecht  leaves  a  lot  of  room  for  encneouscaiegoiizatioo,  and  is  therffore  less  Objective.  Capen 
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Jones  punts  out  that  although  Dreger’s  book  successfully  establishes  consistent  rates  for  counting  finction 
points.  Dieger  varies  from  the  way  Albrecht  counts.  "NothUy.  Dr^er  tends  lo  accumulate  slightly  more 
kinds  of  things  for  inputs,  outputs,  and  inquiries  than  would  be  normal  when  using  the  router  (Albrecht) 
IBM  method*'  (18:98-99).  Besides,  having  to  master  an  the  rules  that  fiU  a  book  is  not  a  good  candidate 
for  making  easy  size  estimates  before  the  project  b^ins.  Also,  Albrecht’s  category  for  logical  files  is  not 
easily  applied  to  relational  databases.  Symons  list  other  aminguities.  He  notices  a  problem  with  on-line, 
interactive  transactions,  where  the  same  screen  processes  inputs  and  ouqxits,  and  he  asks  several  questions: 

•  Is  the  screen  to  be  counted  as  an  iiqxit  or  ouqjut  or  both  ? 

■  Are  the  logical  file  references  (which  we  need  to  know  for  determining  conqitexity)  made  finm  the 
input  or  the  output,  or  both  ? 

•  Is  a  retrieve-before-update  the  same  as  an  inquiry  ?  (33:19) 

Of  all  the  sizing  techniques  reviewed,  Mark  n  hmcdon  points  appear  to  be  both  unamlnguous  and 
easy  to  estimate  before  a  project  b^ins.  Fbr  these  reasons.  Symons’  distinct  categorization  of  itqmts, 
ouqiuts,  and  entities  will  be  used. 

IIL3  Oracle  Software  Measurement 

The  first  stqi  is  to  identify  the  Mark  II  iiqaits,  entities,  and  outputs  invtdved  with  a  given  Softwme 
Enhancement  Request  (SER).  Inputs  comprise  that  pst  of  the  srrftwaie  associated  with  display  preparation 
and  data  entry  validation.  Ouqwts  are  associated  with  preparation  for  diq>lay  or  printing.  Entities  involve  all 
work  between  the  inputs  and  outputs,  such  as  database  accesses  and  data  manipulations  (33:87).  Symons 
sununarizes: 


The  task  then  is  to  find  properties  of  the  input,  process,  and  oidput  components  of  each 
logical  transaction  type  which  are  easily  identifiable  at  the  stage  externd  design  of  die 
systems,  are  intelligiHe  to  the  user,  and  can  be  calibrated  so  diat  the  weights  for  each  of  the 
components  are  based  on  practical  eiqietience  (32:4). 

For  the  Oracle  database  management  system,  S(^*Forna  and  S(H>*Repom  components  were 
nupped  to  fimctten  points  as  defined  by  Symons.  A  trigger  step  is  associated  with  data  entry  validation 
and  cursor  movement,  so  it  was  nupped  to  Mark  n  inputs.  A  S(H<*Rqxvt  did  not  have  hpots  counted 
since  it  is  not  used  for  data  entry  into  the  database.  $(^*Fonns  are  baaed  on  fields  that  define  how 
the  output  will  look,  so  fields  were  counted  at  Mark  n  ouputt.  S(^*Rq)Qtit  use  ’select’  statements  to 
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extraa  rtatrtiay.  entries  for  subsequent  output,  so  ’select’  stttements  were  nuqiped  to  Mvk  0  ouqwts. 
SQL*Focnis  have  one  or  more  blocks  that  are  based  on  ^  tables  or  entities,  and  are  used  to  retrieve 
and  manipulate  data.  The  blocks  were  counted  as  Muk  n  entities.  S(^*RepQrts  are  also  based  on  taUes, 
so  tables  couitt  as  Mark  n  entities.  A  single  S(^*Fofm  itself  was  counted  as  a  Marit  n  transaction,  as  was 
a  S(^*Repott  This  mappiog  Mark  n  fonction  points  to  Oracle  conyonents  shown  in  IhUe  3  satisfies 
both  guiding  principles  for  selecting  a  measurement  technique  staled  in  the  overview: 

1.  unambiguous  and 

2.  easily  estimated  before  the  project  begins. 


lUtk  3 


Mapping  Oracle  Components  to  Mark  II  Fonction  Points 


Mark  n  Ibrminology 

SQL*Forms  Ibtminology 

S^*Rqx)rts  Tstminology 

Ihuisaction 

A  form 

A  report 

Input 

Irigger-stq) 

n^ 

Entity 

Block 

Ihble 

Ouqwt 

Field 

Select 

First,  blocks,  fields,  and  trigger-stqM  are  sufficiently  nnamlnguous  that  one  cannot  be  confused 
with  the  other.  Second,  the  mapping  allows  for  easy  estimates  because  the  programmer  can  characterize 
software  size  in  terms  of  ftuniliar  and  meaningful  Oracle  conq)Ok<ents.  The  progiammen  provided  the 
function  points  count  after  both  the  analysis  and  the  design  were  completed.  The  environmental  factors  ve 
considered  stable  and  not  varying  across  projects,  arul  so  were  not  used  to  adjust  the  futKtion  points.  An 
illustration  of  the  functional  model  for  counting  is  shown  in  IhMe  4,  which  revises  Thbie  2  on  page  IS  in 
ChqNer  Two  by  substituting  S(^*Farms  and  SQL*Repocts  terminology,  with  the  Mark  n  tennincfiogy: 
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lUk  4 


SQL^Fonu  aad  SQL*Rcporti  Fnctkw  Foist  Cooat 


SQL*PORMS  or 

HUGGER-STEPS 

BLOCKS  or 

FIELDS  or 

S(^*REPORTS 

TABLES 

SELECTS 

(transactions) 

(inputs) 

(entries) 

(outputs) 

AddLCustomer 

S3 

1 

3 

In(piire_Stock 

2 

3 

10 

Add_Header 

20 

2 

12 

AdcLItem 

6 

5 

6 

Inquire.Quantity 

2 

4 

4 

Rqx>it_Stock 

1 

3 

21 

TOTAL 

84 

18 

S6 

EflOrt  and  Schedule  Measarement 

Symons  measures  effoit  and  schedule  in  units  of  wosk-houn  and  cakadar-weeks.  He  defines  woric- 
hours  as  "one  hour  of  worit  by  one  person,  including  normal  persorud  breaks,  but  excluding  migor  breaks 
such  as  for  lunch”  (33:84).  The  programmers  recorded  the  number  of  hours  spent  exclusively  on  a  given 
project  per  person.  Any  hours  qmt  on  activities  other  than  the  project  were  not  included  in  the  project's 
work-hours.  For  a  two-person  team,  the  team’s  work-houn  were  the  sum  of  each  programmer's  hours. 
The  measurements  were  accurate  to  one  tenth  cX  an  hour. 

The  programmen  recorded  the  number  of  calendar-weda  fitom  the  day  the  project  began  to  its 
oomidetion.  The  coum  kA  calendar-weeks  included  work  on  the  project  and  any  other  demands  qxn  the 
programmers.  Ibe  count  of  weeks  was  for  the  project  nd  did  not  vary  by  team  conyoaition  at  did  the 
measurement  of  work-hours.  The  measurements  are  acemte  to  one  tenth  of  a  five-thqr  week,  or  about 
half  of  a  day. 

IIL5  Data  CoBcction  Program 

A  data  collection  program  is  listed  in  ^tpendix  H,  and  was  wrinen  to  assist  widi  data  coUectioo 
in  two  ways.  Rrst,  the  program  will  simply  prompt  for  the  size  of  the  software  support  characterized  in 
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tenns  of  Maik  n  function  pcnnis  that  ate  added,  changed,  or  deleted.  Second,  the  program  provides  the 
option  of  ‘sizing  by  analogy’  in  the  case  of  an  entirely  new  transaction  being  added.  Sizing  by  analogy  was 
accomplished  by  scanning  Oracle  DBMS  data  dictionary  rqxMls.  An  examine  of  a  data  dictionary  npon 
is  listed  in  Appendix  F.  The  data  ctriketion  program  is  written  in  the  Ada  language.  The  program  could 
have  been  written  using  SQL^Rqxxts,  thereby  directly  awvtMing  nie  data  dictionary  at  the  same  time  as 
providing  automated  assistance  with  sizing  and  estimating.  However,  the  expressiveness  and  generality  of 
the  laitguage  was  uncertain  at  the  b^inning  of  the  development  (tf  the  program.  With  Ada,  the  development 
was  uneventful  due  to  the  availability  of  a  debused  libiary  oS  reusable,  generic  coitqxnents  known  as 
the  Booch  Coitqronents  (7:71). 

For  purposes  of  sizing  by  analogy,  the  SQL*Forms  source  code  will  be  reduced  to  the  parts  essential 
for  coiBiting,  using  a  DEC  VAX  DCL  cottunand  file  listed  in  Appendix  E.  that  invokes  a  n^ular  expression 
parser,  ‘fgrep*.  The  parser  reads  search  pattons  from  the  file  fjp2je.  also  in  Appendix  E.  If  any  lines  in 
the  data  dictionary  rqxxt  contain  the  search  patterns,  then  those  lines  are  written  to  a  different  file  for 
the  function  point  counting  portion  of  the  data  coUection  program  to  read.  An  examine  of  reduced  source 
code  for  a  SQL*FOrm  is  in  Appendix  E.  and  shows  trigger  steps,  blocks,  and  fields.  Symons  suggests 
computing  "Mark  n  unadjusted  frinction  posits  automatically  from  a  frnctional  nrodel  of  a  qrstem  stored 
for  example  in  a  data  dictionary"  (32:10).  Ihe  output  from  an  Oracle  SQL*Reports  program  in  ^ipeadix 
G  for  extracting  a  functional  nnodel  from  the  data  dictionary  is  the  input  to  the  tegular  expression  parser 
that  reduces  the  data  dictionary  rqiort 

When  an  analyst  receives  a  software  engineering  request,  analysis  is  performed  and  the  extent  of 
changes  necessary  ate  identified  and  collected.  The  analyst  first  invokes  the  Digital  Equipment  Corporation 
VAX/VMS  control  language  command  file  that  reduces  the  size  of  the  source  code  reports  to  be  used  for 
estimating  by  analogy.  When  sizing  by  analogy,  the  data  entry  program  will  scan  the  reduced  S(^*Forms 
source  listitig  for  Mark  n  function  points.  The  strftware  sqiport  requested  by  the  SER  will  be  broken 
out  into  additions,  changes  and  deletions  of  irqxus,  processes,  ouqxits  and  entire  forms  anrVor  rqxxts. 
Hie  data  ccrilection  program  will  provide  a  prompt  for  sizing,  estimating  or  reporting  actual  results.  After 
choosing  die  sizing  option,  the  analyst  enien  a  one  to  five  digit  SER  number,  and  each  member  of  the 
team  workiitg  on  this  particular  SER.  A  brief  exfdanation  is  displayed,  requesting  forms  or  reports  to  be 
added,  changed  or  deleted  to  support  the  SER. 

•  Added  means  creating  a  completely  new  form  or  report 
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•  Changed  means  that  within  an  existing  fonn  (or  iqot),  bloda.  fields,  and/or  stq»  (or  tables  and 

selects)  will  be  added,  changed  or  deleted. 

•  Deleted  means  compleiely  deleting  an  existing  form  or  iqxnt 

The  analyst  is  now  prompted  for  one  or  more  of  foe  software  siq)i)Oit  actions  for  one  or  more  forms. 
If  foe  analyst  chooses  to  enter  forms  that  need  to  be  added,  an  explanation  appears  telling  that  the  form  size 
win  be  by  analogy  to  an  existing  form  with  which  analyst  is  fomiliar.  If  the  analyst  chooses  to 

enter  existing  forms  that  need  to  be  changed  or  deleted,  then  piomptt  qipear  to  receive  foe  names  of  foose 
forms.  The  program  then  dis|riays  a  message  teUing  the  analyst  font  it  is  scanning  foe  forms  to  count  Mark 
n  iimction  pdnts,  and  then  prompts  for  changes  within  foe  forms  that  were  identified  as  requiring  changes. 

First  the  program  asks  how  many  trigger  stqis.  blocks  or  fields  wiU  be  added.  Next,  it  asks  how 
many  trigger  steps,  blocks,  or  fields  wiU  be  changed.  Last,  how  many  trigger  8tq>s,  blocks,  or  fields  will 
be  deleted.  The  program  then  returns  to  the  main  menu  and  at  this  pifott  the  analyst  selects  the  Estimate 
option.  The  screen  displays  the  size  of  the  currait  SER  in  terms  tit  Mark  n  Iimction  points.  At  the  main 
prompt,  the  analyst  can  enter  a  question  mark  and  receive  elaboration  of  the  data  entry  process.  After 
the  SER  is  completed,  the  analyst  rqxxts  woric-hours  spent  on  changes  and  testing,  and  calendar  weeks 
dapaed  during  changes  and  testing. 

IIL6  Summary 

lb  satisfy  foe  research  objective,  the  method  tit  answering  foe  investigative  questions  related  to 
software  siq)port  sizing,  effort,  and  schedule  measurement  is  described  in  this  chapter.  As  a  result  of  the 
literature  review  the  chosen  software  size  measine  is  Mark  n  fimction  points.  The  reason  for  this  choice 
is  that  Mark  n  fimction  points  are  both  unambiguous  and  easy  to  estimate  before  a  project  begins,  and 
meaningfully  coneqaaid  to  the  scrftware  stqjport  requiremem.  The  environmental  Cacton  within  SCV  are 
considered  stable  and  not  varying  across  projects,  and  were  not  used  to  adjust  the  fimction  points.  Mark 
n  fimction  points  are  nuq)ped  to  Oracle  database  software  components  in  S(2L*Fbrms  and  S(^*Rcpoits. 
Software  assisted  wifo  data  collection  and  sizing  by  analogy,  usiog  the  data  dictionary  rqxxts  produced 
by  an  Oracle  SQL*Rq)otts  program  used  by  the  SCV  programmers. 
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IV.  Eatimatliig  Methodology 


IV.1  Overview 

Several  models  for  predicting  profect  effixt  and  actaednle  were  constructed  to  satisfy  the  research 
objective:  to  eatimate  the  esqtecied  software  suppon  effort  and  schedule  given  the  size  cff  an  Oracle 
database  sctitware  siqipoft  request  This  chapter  addresses  the  investigative  question  related  to  estimating: 
What  is  the  relationship  between  the  size  and  effort  or  schedule?  In  addition  to  the  selection  of  Marit  n 
function  pdnts  as  the  software  unit  of  measure.  Symons*  lenninology  fix  effort  and  schedule  units  were 
also  used,  namely,  work-hours  and  calendar-wedcs  (33:140-142).  Descriptive  statistin  were  used  to  focus 
the  r^resskxi  aiudysis.  The  software  used  for  analysis  was  die  Statistical  Analysis  System  (SAS).  Vdthin 
SAS  a  procedure  known  as  FROC  CHART  provided  histograms  for  the  data  (28:69-95)  and  FR(X:  REG 
performed  the  regression  computations  (29:773-876). 

Having  chosen  Mark  n  function  points  as  the  metric,  it  would  have  been  conveniem  to  use  a 
commercial  off-the-shelf  cost-estimation  tool  based  on  Mark  n  function  pmnts.  Aconqxny  namedStrat^ic 
Systems  TecluKdogy  provides  just  such  a  software  cost-estimating  lord  called  Befixe  Yon  Leap  n.  or  BYL 
n.  Symons  cites  it  for  its  ease  of  use  and  flexibility  (33:177).  Unfortunately,  BYL  n  was  not  available 
for  this  research. 

TV2  Popuiathm 

The  populations  of  interest  dqiend  on  the  composition  of  the  progranuning  teams.  If  one  individual 
is  working  on  the  project,  (hen  the  population  of  interest  is  the  individual’s  reqxxise  to  the  sue  of  the 
software  support  requested  as  measured  in  Mark  n  function  pcrints.  If  two  individuals  me  working  on  the 
team,  then  the  population  of  interest  is  the  reqxxise  for  that  particular  pair  of  programmen.  For  a  project 
requiriiig  two  programmers,  the  need  for  httetpersonal  communication  and  coordination  adds  an  additional 
activity  to  the  effort,  and  therefore  a  different  population  of  reqxmses  than  for  a  siiigk  programmer. 
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IV3  Descriptive  Analysis 


The  desf  iptive  analysis  tabulates  and  summarizes  the  observed  teams’  responses  to  given  levels  of 
serftware  support  requests  as  measured  by  Maikll  function  pmnts.  The  response  is  measured  in  work-hours 
expended  within  a  schedule  of  calendar  weeks.  The  ■tnrittimi  software  procedure  SAS  FROC  CHART 
created  histograms  of  the  data  collected,  which  are  listed  in  Appendix  A.  Also,  scatter  plots  graphically 
display  the  relationship  between  function  points  and  effort  or  schedule. 

IV4  Regrasion  Analysis 

A  regression  analysis  was  performed  to  determine  the  nature  of  the  relationship  between  the  predictor 
(Mark  n  function  points)  and  the  response  (effort  and  schedule)  by  means  of  a  least  squares  best  fit  (^BF) 
regression  line.  Figure  4  illustrates  a  simple  regression  {fiot  relating  function  points  to  effort 


Figure  4.  Effort  vs.  Function  Points  Plot 
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TVJ  Indicator  Variables 


Tb  allow  fw  different  teams’  responses  to  the  same  level  of  fimction  pmnts,  indicator  variables 
denote  team  compositkm  in  the  regression  models.  Four  teams  (A,  B.  C.  and  D)  would  be  denoted  with 
only  three  indicator  variables  (Ii.  I2.  and  Is): 

Ibam  Ii  I2  h 

A  10  0 

B  0  1  0  (13) 

cool 

D  0  0  0 

Ibam  D  is  rqjresented  in  this  model  when  all  three  indicator  variables  are  etpial  to  zero.  A  modd  with 
three  indicates  variaUes  would  have  to  estimate  a  slqie  and  intercqM  for  each  of  the  four  teams,  or  eight 
puameters  (21:351).  With  12  observations  though,  estimating  ei^  parameters  reduces  the  degrees  tff 
freedom  to  four.  Consequently,  (xdy  one  indicator  variable  was  used  to  denote  a  two-member  team  versus 
a  single  programmer,  preserving  eight  degrees  of  freedom  for  estimating  four  parameters.  The  indicator 
variable  assumed  the  value  of  one  for  team  D,  and  zero  otherwise.  Of  the  four  teams,  team  D  was 
subjectively  determined  to  have  responses  likely  to  differ  the  most  from  other  teams.  Since  team  D  is 
the  only  team  with  more  than  one  programmer  it  has  a  line  of  communication  between  programmers  that 
the  other  teams  do  not  have.  Teams  A,  B,  and  C  rqxesent  three  different  individual  programmers.  These 
classifications  lead  to  the  initial  models  for  effot  and  schedule. 

IV,6  Effort  Model 

Work-Hours  «  /?o  +  ^lufp  +  ^al  +  AlufjP  «• 

•  IsQ  :  Work-Hours  *  00  0ivtp  4e,  for  teams  A,  B,  and  C. 

•  1=1  :  Work-Hours  ^  (0o  *  02)  +  (0\  +  0i)  vfp  *  ^  foi  learn  D. 

IV.7  Schedule  Model 

Calendar-Wedu  =  0o*0ivfp  02l+  03lafp  *  e. 

•  1=0  :  Calendar-Weeks  *  0o  +  0ivtp  *  e,  for  teams  A  and  B 

•  1*1  :  Calendar-Weeks  ■  (0o-^  02)  *  (0i*  0i)iify*t,  for  team  D. 

Several  statistics  woe  calculated  from  the  data  and  correlated  to  the  criteria  in  die  ftdlowing  secdoos. 
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IV^  F-Ratio 

The  risk  of  a  lype  I  enor  was  controUed  at  a  significance  level  of  0.10  forliie  F  tests. 

•  Hb:  •  02  03  ^  0 

•  Ha:  not  all  parunetets  are  zero. 

Critical  Vslue:  The  critical  value  for  the  F  statistic  is  F(at^.lOj>-l,n-p). 

Decision  Rule: 

•  If  F*  ^  Foil  then  do  not  reject  the  null  hypothesis. 

•  If  F*  >  Feht  then  reject  the  null. 

IV.9  Parameters 

The  risk  of  a  IVpe  I  error  was  controlled  at  a  significance  level  of  0.30  for  the  t  tests. 

•  Ho:  0\  •  0,  and  Ha:  0i  <  >  0 

•  Ho:  02  0.  and  Ha:  02  <>  0 

•  Ho:  03  •  0,  and  Ha:  02  <>  0 

Critical  >^ue: 

Die  critical  value  for  the  t  statistic  is  t(ai«0.304ii>)- 
Decision  Rule: 

•  If  k*l  ^  teat  then  do  not  reject  the  null  hypothesis. 

•  If  k*l  >  tcA  then  reject  the  null. 

Once  a  linear  model  was  developed,  hs  specification  was  assessed.  Because  (tf  the  small  number 
of  obsovations  it  was  not  practical  to  test  for  hmeroscedasticity. 

IV.10  Model  spedfleathm 

A  plot  of  residuals  against  the  independent  variaUe  was  examined  for  each  model.  The  nonlinearity 
of  a  model  was  checked  by  visually  inqweting  this  residuBl  plot  for  pattens  such  as  the  hninp  in  Figure 
5,  or  perhaps  a  *U’  shape. 
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Rendnali 


Mall 


Figure  5.  Residual  plot  against  independent  variable 


IV.11  Distribution  of  error  terms 


The  assumption  ai  tbe  regression  model  is  that  the  ereor  lenns  are  uofmaDy  distiibutBd  with  a 
constant  varumce.  IMth  a  very  small  data  set  it  is  very  difficult  to  test  for  these  assunqxioos.  The 
normality  of  the  error  terms  was  evaluated  by  plotting  die  residuals  firom  each  model  as  a  histogiam.  If 
the  histogram  was  reasonably  symmetrical,  residaals  were  assumed  to  be  normal. 

IV.12  Outliers 


respea  to  X: 

The  hat  matrix  statistic  was  used  to  delect  outlien  with  leqiect  to  die  hidqiendent  variable.  The 
SAS  FROC  REG  computes  the  hat  matrix,  which  expresses  fitted  values  as  a  finear  combination  of  the 
dqiendem  variables  using  the  elements  of  the  hat  matrix  H  =  X(X'X)~*X'.  Hie  diagnnal  demems 
of  the  hat  matrix  (hiO  are  called  leverage  values.  A  leverage  value  indicaies  whether  the  i-th  case  is 
disunt  fiom  the  center  of  all  indqieiident  variable  observackns.  Hie  leverage  is  considered  huge  if 
hii>2xTi,  where  ^  so  hu  >  ^  indicates  an  ondier  (21:395-396). 

With  reqiect  to  Y: 

The  SAS  FROC  REG  provides  studentized  deleted  residuals,  which  were  analyzed  to  delect  oudkn 
with  respect  to  die  dqiendeot  variable.  Studentized  deleted  residuals  with  abaointc  vahres  >  t(a,aip*l), 
were  considered  exneme  oudkn  at  a  kvd  of  signiflcaooe  of  o^OS. 
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rV.13  lafluential  Outliera 


The  next  stq>  is  to  asceitain  the  influence  of  outlying  oheervatioas.  using  the  statistic  DFFTTS, 
provided  by  SAS  PROC  REO.  The  stands  for  difference,  and  WFITS  is  the  difference  between: 

•  the  fitted  value  for  the  i*th  case  when  all  n  cases  ate  used  in  fining  the  regression  function  and 

•  the  fitted  value  for  die  i-th  case  obtained  when  the  i-th  case  is  omitted  in  fitting  the  r^iession 
function. 

It  is  standardized  so  diat  the  value  (DFFTTSX  for  the  i-th  data  point  tqitesents  roughly  the  number 
of  estimated  standard  deviations  that  the  fitted  value  changes  when  the  i-th  case  is  removed  firom  the  data 
set  (21:401): 


{DFFITS)i  = 


yj-Yid) 


(14) 


If  the  influence  stadsdcs  exceed  estaUished  cutoff  values,  further  investigation  is  warranted.  For 
small  data  sets,  the  observadon  is  considered  influential  if  DFFITS>  1.  Ifobservadons  tested  as  influential, 
an  in-dqKh  analysis  was  performed  to  dMermine  if  the  outlier  was  the  result  of  measurement  error  or  some 
other  distortion,  otherwise  a  cursory  analysis  was  done. 

When  a  linear  r^resskxi  model  is  fitted  to  a  data  set  with  a  smaD  number  of  observations 
and  an  outlim  is  present,  the  fitted  regression  may  be  so  distorted  by  the  oudkr  that  the 
residual  plot  suggests  a  lack  of  fit  of  the  linear  regressioo  model  in  addition  to  flagging  the 
outlier  (21:122-123). 

IV.14  CoDincarify 

CoUinearity  is  a  problem  arising  from  two  or  more  independent  variables  being  hi^y  correlated  with 
each  other,  and  are  cttincidentany  eiqflaining  the  same  total  sum  of  flie  squares.  "Hie  overall  question  when 
testing  for  coUinearity  is:  what  is  the  significance  (rf  the  relations  among  die  predictors?"  (27:37)  When 
predicton  are  correlated,  the  regression  coefficient  of  any  predictor  depends  on  which  other  predicton 
are  included  in  the  model,  and  which  are  left  out  Four  key  questions  that  can  be  answered  easfly  if 
predicton  are  uncorrelated: 

1.  What  is  the  relative  importance  of  the  effects  of  differeat  predictor  variaUes  ? 

2.  What  is  the  magnitude  of  the  effect  of  a  given  predictor  on  the  leqxmse  varitiUe  ? 
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3.  Can  we  drop  one  or  mote  piedictors  without  significantly  affectmg  the  ejqrianatoiy  power  ci  the 

presumed  model  ? 

4.  Should  any  other  piedicion  be  included  in  our  model  ?  (27:37) 

,  Condition  numbers,  uderance  (TOL),  and  were  eaamined  for  indications  of  ooDinearity.  There 

are  actually  two  measures  of  R^.  The  more  common  one  is  in  the  ANOVA  table  and  it  is  based  on  the 
*  dqtendent  vaiiaMe  Y  as  a  function  of  the  independent  variaMes.  or  Y  = /(Xi,A'3,Xs,A‘4),anditwillbe 

denoted  as  Ry.x-  ^  the  puqxMes  at  odlinearity  diagnosis,  another  coefficient  determination  is  used 

which  is  based  on  the  indqiendent  variaUe  in  question  being  a  function  of  die  other  indqiendent  variables, 
or  A-i  =  fiX2,Xa,X4),  and  it  will  be  denoted  as  R\. 

CoUinearity  and  tokrance  diagnostics  examined  indicators  of  cotrelaiioo  among  independent  vari¬ 
ables.  using  the  SAS  PRCX^  REO  options  TOL  and  CCXUNOINT  (ccdlinearity  with  no  intercept  ocdumn 
in  the  design  matrix).  Ccfilineaiity  exists  if  a  condidon  number  is  greater  dian  one.  If  the  condition 
number  >  10,  then  the  model  may  be  adversely  affected  by  coiUnearity.  Ihe  TCX.  option  requests  the 
tolerance  values  for  the  parameter  esdmates  based  on  ^*h  TOL  =  1  -  R^,  a  TOL  <  0.10  may 
indicate  that  coOinearity  is  influencing  the  least  square  estimates.  The  coefficient  d  determination  firom 
the  ANOVA  taUe,  R^.x>  ^  oompved  against  R^  =  l-  TOL,  If  R^x  <  ***"  coUineari^  was 

determined  to  be  present 

IV.15  Prediction  Intervals 

A  new  observation  of  work-hours  or  cakndar-weeks  coneqxmdiqg  to  a  given  levd  of  function 
points  is  viewed  as  the  result  of  a  new  trial,  indqiendent  at  the  trials  on  whidi  the  regression  analysis  is 
based.  Prediction  of  a  new  observation  is  subject  to: 

•  variation  in  possible  locations  of  the  distribution  d  work-hours  or  cakodar-wedo,  and 

•  variation  within  the  probability  distribotion  of  work-hours  or  cakndar-weeks  (21:81). 

Since  the  true  mean  response  is  unknown,  with  eirBO.20  the  poim  estimator  Yk  wiD  be  used  to 
constnict  a  prediction  interval: 


“  fot,o-p  *  *Yk(..«)  S  Y|  <  +  ta^-p  X  aYk(,„) 


(15) 
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IV.16  Sumary 


Data  was  collected  and  is  displayed  in  Appendix  A  along  with  desaqitive  statistics  firom  SAS 
PROCs  CHART  and  REG.  Hie  pfQgramfneis'  effon  and  schedule  leqxmses  to  a  given  level  ot  tuppon 
were  modeled  with  indicaior  variaUes.  After  an  assessment  was  made  of  the  model  qiecification,  each 
model  was  tested.  Then  a  final  effort  and  schedule  model  was  chosen  and  assessed. 
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V.  Analyris 


V.1  Dcforiptivc 

Hie  obtervatians  listed  in  ^ipeiidix  A  on  page  58  ivere  coBecied  from  all  penoanel  avaiUUe  to 
participoie  in  the  leseaich.  In  addilkn  to  the  enlistffrt  prognmmer  tmnoven.  the  SCV  software  snppoit 
enviromnentttansitioned  to  a  new  contractor  osganizationdming  this  data  collection.  The  previous  snppott 
contract  was  tenninated  and  a  new  conqnny  began  sopporting  the  AFTT  Oracle  baseline  at  about  the  time 
data  collection  began.  As  a  consequence.  Oracle  dathhaie  support  activity  was  below  nonnal  ttaooghout 
the  data  collection  period.  The  data  include  Mark  n  ftmction  points  supported  by  a  portkular  Software 
Enhancement  Request  and  the  number  of  woric  hours  expended  by  the  team  towards  coding  and  testing 
the  SER  during  a  period  of  calendar-weeks.  Ihe  data  was  collected  per  programming  team,  per  project 
INvelve  observatians  were  collected  from  AFTT/SCV  personnel  during  the  period  April  through  June  1992 
and  are  summarized  in  Ihble  9  in  ^jpendix  A  on  page  58.  Three  of  the  observations  were  for  teams 
comprised  ci  two  enlisted  programmers,  and  nine  were  for  individnab.  Ihree  of  the  obaervatioos  were 
for  a  single  contractor,  and  the  test  were  far  enlisted  ptogeammers.  Rve  were  far  S(^*Fonns  siqtport 
and  seven  far  SQL*Rqiatts.  A  cnrsoty  inspectian  of  the  data  showed  some  anomaliea  in  the  schedule 
observations.  Team  C  appeared  to  have  a  consistently  higher  reqxmse  to  a  given  level  of  fanctioo  points 
than  the  other  teams.  The  observations  ate  considered  accurate  because  the  data  collection  was  carefully 
conducted.  The  significant  dififetenoe  in  the  team  C  response  can  be  aitrfaoted  to  the  fact  that  team  C  was 
internq)ied  frequently  during  period  (tf  time  when  die  new  conqiany  was  settling  into  the  SCV  envitonroem. 
These  unique  interruptions  ate  qwcial  causes  of  variation  and  are  not  likely  to  recur.  The  team  C  schedule 
reqxmse  will  be  deleted  for  the  purpose  building  a  schedule  anodd.  The  q0hrr  observadons  for  team  C 
will  not  be  deleted  because  in  spile  of  the  huemqNioos,  die  qiplied  effart  was  not  uousud. 


\2  Rcgraaskm 

The  SAS  procedure  TtEO*  was  used  to  test  die  models  far  predicting  effart  hi  wok-hoon  and 
in  calendar-weeks  bared  on  die  of  fincdon  ppttt  supported.  Bared  on  prelimiiiaiy 

analysis,  an  indicator  variable  was  introduced  far  quand^dng  the  two  cases  as  described  in  Chapter  Four. 
The  bidicaior  variable  (I)  takes  on  the  value  of  one  for  the  observations  of  team  D.  and  zero  otherwise. 
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V  J  Effort  Model 


VJ.J  Descriptive  Statistics 

Thae  were  12  otaervaiioiis  oaed  lo  build  diis  model  The  effort  model  deocribes  the  irJetkwohip 
betwemi  the  predkior  level  of  functioo  poiiits  nd  die  effort  reqiODse  in  work-hoon.  Moit  of  the 
obeervmioiis  ve  at  a  level  of  10  function  points  or  less  as  shown  in  the  hisiognm  in  Appendix  A  on 
page  58.  The  scatter  plot  on  page  60  highlights  the  piqiondenmce  oi  data  at  10  function  points  or  less. 
There  is  a  generaOy  linear  appearance  to  die  reladooship  between  funcdon  points  nd  wotk-hours.  but  with 
only  two  obaervadoos  greater  than  10  function  pnnu  tte  possibility  of  a  nonlinrar  relationship  existt.  For 
the  purposes  of  this  research  a  linear  relatkxishjp  is  assumed. 

VJ.2  Indicator  Variables 

The  values  of  the  indicator  variaUes  are: 

•  I  «  0  if  team  A,  B.  or  C,  (single  programmers). 

•  I  a  1  if  team  D  (two  programmers). 


MOKL  :  WorkHours  =  0.538052  +  1.992678  x  u/p->  10.814188  x  7  +  2.175083  x  lufp  (16) 
Team  A,  B,  C  :  WorkHours  =  0.538052  + 1.992678  x  nip  (17) 

Ihaai  D  :  WorkHours  =  -10.276136  +  4.167761  x  uQi  (18) 


200  hn 


Figure  6.  Effort  Model  Regrwion  Lincf 
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VJJ  Co^icient  of  Determination 

In  Appendix  B.l  on  page  62  the  value  for  this  model  was  0.97S9,  whidi  indicates  that  97.6 
percent  ai  the  estimating  error  when  the  estimate  is  based  on  the  mean  reqionae  is  e]q)lained  by  the 
relationship  between  hours  and  function  points. 


V3.4  F-Ratio 

Critical  >Uue:  The  critical  value  for  the  F  statistic  is  F(a^.l03.8)B2.92  (21:636). 

Decision:  The  F*  value  in  die  ANOVA  table  in  ^jpendix  B  is  108.136  which  is  greater  than  232, 
so  reject  the  null  hypothesis. 

Claim:  Hie  probability  of  obtaining  an  F-ratio  greater  dian  106.136  if  hours  was  not  a  function  of 
UFP  is  less  than  0.0001.  The  reladonship  appears  to  be  very  significant 


VJJ  Parameter  Tests 

Critical  >Uue:  The  critical  value  for  the  t  statistic  is  t(enO303)Bl>108  (21:63(9* 

Decision:  The  values  of  the  t*statisdcs  and  p-values  for  the  parameten  from  the  ANOVA  thMe,  and 
the  decisions  for  each  parameter  are  summarized  in  IbUe  5.  The  least  significant  r^ression  coefficient 


Thble  5 


Eflbrt  Model  ParaaKter  Tnfi 


TERM 

PARAMETER 

t  STATISTIC 

p  VALUE 

DECISION 

u^ 

01 

11j6S8 

0.0001 

R^H. 

I 

02 

1345 

0.1609 

Reject  Ho 

Iu4> 

02 

5318 

Reject  Ho 

was  02  which  was  significant  at  the  0.16  level  of  confidence  which  exceeds  the  criterion  value  of  030 
by  a  oomfortaUe  margin. 
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VJ.6  Model  Specification 

Residual  plots  against  the  indqxodent  vahaMes  in  Appeodia  B2  on  page  63  did  not  reveal  any 
pattenis  that  would  indicaie  a  nonlinear  relationship. 

VJ.7  Distribution  of  the  Error  Terms 

The  enor  distribution  for  the  effoit  model  in  ^ipendix  B.2  shows  some  skewness  to  the  right 
only  12  observations,  however,  it  is  not  certain  whether  ornot  the  error  tenns  are  nonnally  distributed. 
For  this  model  a  nonnal  distribution  is  assumed. 

V3.8  Outliers 

The  criterion  value  for  identifying  outliers  with  respect  to  X  for  this  model  is  ^  ^  =  0.75. 

From  Appendix  B.3,  observations  three  and  nine  had  levenige  values  of  0,97612  and  0,99024  respectively, 
exceeding  the  criteria.  These  observations  have  the  two  largest  fimction  point  values,  S0iS2  and  3236 
respectively.  The  next  largest  observation  had  93  function  points. 

The  criterion  value  for  identifying  outliers  with  respect  to  Y  using  RSTUnBNT  for  this  model 
was  t(ofB>0.05, 7)  >  2365  (21:630).  Only  observation  rix  exceeds  this  criterion  with  a  value  of  2,40519. 
Observation  six  had  only  1.92  function  points  but  yet  took  173  hours  to  conqrieie  This  was  a  large  number 
of  hours  for  the  small  number  of  fiinctioo  points.  The  next  largest  RSTUIKNT  was  observation  duee 
with  only  1.4447,  which  is  not  a  significant  value. 

V3.9  Ir0uential  Outliers 

The  outliers  examined  for  influence  are  three,  six,  and  nine.  From  ^tpendix  B3,  observations  three 
and  nine  had  OTFITS  values  much  greaser  than  the  criterion  value  of  one  (93372  aad  3L9071  reflectively). 
These  were  the  two  observatkms  identified  as  extreme  outliers  with  reqiect  to  X  nd  observations  three  and 
nine  have  the  two  highest  vdp  counts.  If  they  were  to  be  removed  from  die  data,  the  esdmating  equation 
would  change  significandy.  Since  the  scrftware  size  meastaement  in  function  points  was  exact  and  any 
effort  meastaement  error  was  likely  n^liUe,  observadcns  three  and  nine  were  not  removed  for  building 
the  model.  Observation  six,  the  outlier  with  respect  to  Y  has  a  DrrnS  value  close  to  one  (0.9S97),  but 
does  not  rqtpear  to  be  an  influential  oudier,  and  it  is  a  valid  although  perhaps  rare  observation.  No  valid 
reason  was  found  for  removiug  arty  of  the  outliers. 
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V3.10  CoUinearity 

In  Appendix  B  the  bugest  oonditioa  number  was  2j6S931.  which  is  significantly  less  than  the 
criterion  value  of  10.  The  smallest  tolerance  value  was  0.4371  for  lUFP.  This  means  that  when  r^ressing 
,  lUFP  against  the  remaining  indqteodent  varid>les  in  the  model,  the  would  be  0  J629.  This  is  not  a 

huge  value,  considering  the  for  the  model  is  0.97S9.  CoUinearity  does  not  appear  to  be  a  problem 
*  in  this  model 

V3.ll  Prediction  Intervals 

The  prediction  intervals  for  teams  A,  B,  C,  and  D  are  listed  in  Appendix  B.4  on  page  65.  Most 
of  the  predicted  values  exceeded  the  actual  values.  The  prediction  for  obsovation  nine  was  equal  to  the 
actual  value  of  125  worit-hours.  Observation  nine  at  a  level  of  32.36  function  pmnts  is  predicted  to  letpiire 
125.4  work-hours  plus  or  minus  12  work-hours,  80  percent  of  the  time.  For  observation  three,  the  effort 
response  to  a  levd  of  50.62  function  points  was  predicted  to  be  101.4  |fius  or  minus  13.9  work-hours,  80 
percent  of  the  time.  The  prediction  for  the  influential  observation  three  was  the  next  best  at  101  work-houn 
compared  to  the  actual  103  work-hours.  The  next  best  was  observation  11  at  4  work-houis  predicted  for 
1.7  function  points  with  3.6  work-houn  actually  observed.  Predictions  for  levels  of  function  pmnts  at 
observations  one.  five,  and  10  were  also  accqitable.  Observation  six  which  happens  to  have  a  very  large 
residual  value  at  13.4  had  an  actual  value  outside  of  die  predictioa  interval 

The  relationship  between  actual  effort  response  and  predicted  is  piotied  in  Hgure  11  on  page  65. 
It  shows  many  close  predictions  at  low  leveb  of  function  joints  and  the  two  close  predictions  out  at  the 
influential  points. 


V3.12  Closing 

In  qiite  of  the  small  data  set,  die  effort  model  seems  to  predict  ndier  well  q)  to  SO  function  ptnnts. 
The  indicator  variables  produce  a  two-member  team  model  that  show  an  effort  reqxmse  at  a  rate  slighdy 
more  than  twice  that  for  the  one-member  model.  This  seems  to  inqdy  diat  there  is  inefficiency  associated 
widi  two  programmers  ctdlaborating  on  a  project 

Ihis  effort  model  can  be  used  to  estimate  the  effort  response  iq>  to  SO  function  points.  However,  this 
range  includes  a  gap  from  10  to  32  function  pmntt  that  is  inteqmlated  by  the  model  with  the  possibility 
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that  a  nonlinear  relatioaship  exists  in  this  intetpolated  region.  Additional  data  collection  in  this  range  will 
reveal  the  certainty  of  model. 

yA  Schcdnk  Model  One 

V.4.1  Descriptive  Statistics 

Afkr  deleting  three  observatioos  for  team  C.  there  were  nine  observations  used  to  build  this  model, 
and  are  listed  in  ^ipendix  A  on  page  58.  This  schedule  model  describes  the  relationship  between  the 
predictor  level  of  function  points  and  the  schedule  response  in  calendar  weeks.  Indicator  variaUes  were 
used  to  differentiate  between  single  and  two-programmer  efforts. 

As  with  the  effort  model,  most  of  the  fimctkm  pdnts  are  at  a  level  less  than  10  with  two  observations 
above  10.  The  histogram  in  Appendix  A3  shows  dutt  die  distributioo  of  weeks  is  somewhat  different  than 
hours.  Of  the  nine  observations  there  are  six  that  are  less  than  one  wedc  and  three  greater  than  three 
weeks.  The  two  highest  values  of  weeks  correspond  to  the  two  highest  function  point  levels.  The  second 
highest  level  of  function  points  required  the  highest  respoosc  at  four  calendar-weeks.  Observation  one  has 
a  schedule  response  of  three  weeks  for  only  3.58  function  points,  because  the  programmer  encountered 
difificulties  scheduling  testing  with  the  user. 

Looking  at  the  scatter  plot  in  Appendix  A.3  without  observation  one  for  team  A  at  three  weeks 
dqncts  a  relationshv  similar  to  the  effort  model,  bid  with  observation  one  it  looks  almost  nonlinear.  For 
the  purpose  of  diis  research  a  linear  relationship  is  assumed. 


V.4.2  Indicator  Variables 

•  I  >  0  if  team  A  a  B  (single  progrsnnmer). 

•  I  >  1  if  learn  D  (dual  programmen). 


MODEL:  CalendarWetks  =  0.987992  4-  0.038427  x  u/p  -  1.142614  x  /  0.089399  x  /u/p  (19) 
Team  A,  B  :  CalendarWeeks  =  0.987993  +  0.038437  x  u^i  (20) 

Teaai  D  :  CalendarWeeks  =  -0.164633  -f  0.137836  x  titp  (21) 
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Figure  7.  Schedule  Modd  One  Regresdon  Lines 


V.43  Coefficient  of  Determination 

In  Appendix  C  on  page  66,  the  for  this  model  was  0,6894,  sriiich  indicates  that  68.9  percent 
o(  die  estimating  error  when  the  estimate  is  based  on  die  mean  response  is  exjdained  by  the  relationship 
between  weeks  and  function  points. 


V.4.4  F-Ratio 

Critical  Vdoe:  The  critical  value  for  the  F  statistic  is  F(ara0.103.S)E3,62  (21:634). 

Decision:  The  F*  value  in  the  ANOVA  taUe  in  Appendix  C  is  3.7  strhicb  is  just  greater  than  3.62, 
so  reject  the  null  hypothesis. 

Claim:  The  probability  of  obtaiiiing  an  F-ntio  gremer  than  3.7  if  boon  was  not  a  fimction  of  UFP 
is  less  than  0.0965.  The  lelationsh^  appean  to  be  significant 

V.43  Parameter  Tests 

Critical  \Uoe:  The  critical  value  for  the  t  statistic  is  t(aa0303)"l>156  (21:630) 

Decision:  The  values  of  the  t-statiatics  and  p-valoes  for  the  patameten  firom  the  ANOVA  taUe,  and 
the  decisions  for  each  parameter  are  summarired  in  Thble  6.  The  least  significant  regressioo  coefficient  was 
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lU>le  6 


Schedule  Model  One  Parameter  Tests 


TERM 

PARAMETER 

t  STATISTIC 

p VALUE 

DEQSION 

ufp 

01 

1j616 

0.1671 

Reject  Ho 

I 

01 

1.168 

0J954 

Reject  Ho 

luQ) 

01 

1.788 

0.1337  j  Reject  Ho  | 

02  which  was  significant  at  the  0^5  level  of  confidence  which  barely  exceeds  the  crimion  value  of  0  JO. 

V.4.6  Model  Specification 

Residual  plots  against  the  indq)endent  variables  in  Appendix  C2  on  page  67,  did  not  reveal  any 
patterns  that  would  indicate  a  nonlinear  rdationsh^. 

V.4.7  Distribution  of  the  Error  Terms 

The  enor  distribution  [fioited  on  the  same  page  for  the  schedule  model  is  skewed  rig^t,  but  widi 
only  nine  observations  it  is  difficult  to  ascetlain  the  error  distribution.  For  the  puposes  of  this  research 
a  normal  error  distribution  is  assumed. 

V.4,8  Outliers 

The  criterion  value  for  identifying  outliers  with  respect  to  X  for  this  model  is  ^  ^  =  0.89. 

In  Appendix  CJ  on  page  68,  observations  three  and  nine  had  leverage  values  of  0M297  and  0J9824 
respectively,  exceeding  the  criteria.  These  observttioks  have  the  two  largest  fimction  point  values,  S0ii2 
and  32.36  respectively.  The  next  largest  observation  had  9.8  function  points. 

The  criterion  value  for  evaluating  outliers  with  reqrect  to  Y  using  RSTUIXEN  T  for  this  model  was 
t(ar«0.0S,  7)  >  2J65.  Only  observation  one  exceeds  this  criterion  with  a  value  of  5,47349.  Observation 
one  had  only  3.58  function  points  but  yet  took  3  wedcs  to  compleiB.  Hiis  was  a  large  number  of  weeks 
for  the  small  number  of  function  points.  The  next  largest  RSTUIXNT  was  observation  five  widi  only 
1.047,  which  is  not  a  significant  value. 
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VA.9  Ir^uentUd  Outliers 

The  outliers  examined  for  influence  are  one.  three,  and  nine.  In  Appendix  C3,  dbsmations 
one.  three,  and  nine  had  KTTTS  values  much  greater  than  one  (2J29,  3J57,  and  9369  ieq)ectively). 
Observations  three  and  nine  were  identified  as  extreme  outliers  with  req)ect  to  X.  If  they  were  to  be 
removed  from  the  data,  the  estimating  equation  would  change  significantly.  Observations  three  and  nine 
have  the  two  highest  function  point  counts.  Any  effort  measurement  error  was  likely  ne^Ue  and  the 
function  point  coum  was  exact  Observatioos  three  and  nine  were  not  removed  for  building  the  modeL 
Observation  one,  the  outlier  with  respea  to  Y.  has  a  hi^  icsponse  to  a  low  level  of  function  points  because 
the  programmer  encountered  diflSculties  in  scheduling  testiqg  with  the  users,  so  it  is  valid  and  will  not  be 
removed.  No  valid  reason  was  found  for  removing  any  the  outliers. 


V.4.10  CoUinearity 

In  Appendix  C3,  the  largest  ctmdition  number  was  159989,  which  is  significantly  less  than  the 
criterion  value  of  10.  The  smallest  tolerance  value  was  0.4493  for  lUFP.  This  means  fliat  when  r^ressing 
lUFP  against  the  remaining  indqrendent  variables  in  the  model,  the  would  be  05517.  Since  the 
x  model  is  0.6894  which  is  larger  than  05S17,  collinearity  does  not  appear  to  be  a  proUem 
in  this  model. 


V.4.II  Prediction  Intervals 

The  80  percent  prediction  intnvals  for  teans  A,  B,  and  D  are  listed  in  Appendix  C.4  on  page 
69.  About  as  many  of  the  predicted  values  were  hitter  than  the  actual  values  as  they  were  lower.  Ihe 
prediction  for  the  influential  observations  three  and  nine  were  very  close,  as  well  as  obaervation  six.  The 
prediction  interval  for  observation  three  seemed  somewhat  wide  ranging  from  1.1  to  4.8  weeks  for  50.62 
function  points.  The  actual  value  of  observatkai  one,  which  enooutitered  lest  schedule  difficulties,  exceeded 
the  tgiper  bound  of  the  prediction  interval  The  other  observatioiis  were  in  the  intervals  but  all  observations 
excqK  three  and  nine  had  negative  lower  bounds  on  the  predictioo  interval 

The  relationship  between  actual  schedule  response  and  predicted  is  plotted  in  Figure  12  on  page 
69.  It  shows  many  close  predictions  at  low  levels  of  frmction  points,  and  the  two  influential  points  are 
somewhat  close  to  the  predicted  values. 
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VA.12  Closing 

Even  wid)  a  small  data  set.  the  schedule  model  seems  to  predict  Csiriy  well  for  values  (tf  iq)  to 
SO  function  points.  The  indicator  vviables  produce  a  two-meihber  team  model  that  show  a  schedule 
reqwnse  at  a  rate  slightly  more  than  three  times  diat  for  the  ooe-member  model  This  indicaies  diat  diere 
is  inefficiency  associated  with  two  programmers  cdlaboiating  on  a  project 

This  model  can  be  used  to  estimate  the  schedule  response  q)  to  SO  fimction  pmnts.  However,  this 
range  includes  a  gq>  from  10  to  32  function  points  dtat  is  interpolated  by  die  model  with  the  possOnlity 
that  a  nonlinear  relationship  exists  in  this  interpolated  region.  Additional  data  ctdlection  in  this  range  will 
reveal  the  certainty  of  model. 

Since  the  T'  term  in  Schedule  Model  One  was  the  least  significant  at  a  0.29S  level  of  confidence, 
the  next  model  will  examine  the  reiationsh^  widiom  die  T*  term. 

\JS  Schedule  Model  2 

VJ.J  Descriptive  Statistics 

This  schedule  model  describes  the  relationshq)  between  the  predictor  level  of  fimction  pmnts  and  the 
schedule  response  in  calendar  weeks.  Only  three  parameters  are  estimated  in  this  model  die  coefficients 
of  ufp  and  lu^,  and  the  intercept  The  least  significant  term,  T’,  in  Schedule  Model  One,  was  dropped 
fin’  this  model 

VJ.2  Indicator  Variables 

The  indicator  variables  assume  the  values: 

•  I  *  0  if  team  A  or  B  (single  programmer). 

•  I  «  1  if  team  D  (dual  programmers). 


(22) 

(23) 


MODEL  :  CalendarWeeks  =  0.68226 -I-  0.046844  x  ufp+  0.049292  x  lufp 
Team  A,  B  :  CalendarWeeks  =  0.68226  -I-  0.046844  x 
Team  D  :  CalendarWeeks  =  0.68226  +  0.096136  x  uQi 


(24) 
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Figure  8.  Schedule  Model  IW  Regrenion  Lines 


VJJ  Cotifficient  of  Determination 

In  Appendix  D  on  pege  70,  the  R^  x  ^  modd  was  0,6046,  which  indicates  Oat  60,5  penent 
of  the  estinuting  enor  when  the  estimate  is  based  on  the  mean  leqnose  is  ejqilained  by  die  irlationship 
between  calendar*weel3  and  function  paints,  tod  this  is  less  than  Schedule  Model  One. 


VJ.4  F-Ratio 

The  critical  value  for  the  F  statistic  is  F(aa0.10,  2,  S)i^M  ^1:634). 

Decision:  The  F*  value  in  the  ANOVA  taUe  in  Appendix  D  is  43n  uiiich  is  greater  than  3.46 
so  reject  the  null  hypothesis. 

Claim:  Ihe  proboirility  of  obtaining  an  F-otio  greater  than  4.588  if  weeks  was  not  a  ftmctian  of 
UFP  is  less  than  041618.  Ihe  relationsl^  appean  to  be  signiticant. 

VJJ  Parameter  Tests 

Critical  Vdue:  The  critical  vdue  for  the  t  statistic  is  t(an4)J0j6)*L134  (214S30) 

Decision:  The  values  of  the  statistics  and  p-values  for  the  parameters  fion  the  ANOVA  table,  and 
the  decisions  for  each  paiameter  are  summariaed  in  Ihbie  7: 
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1U>le  7 


Schcdide  Model  Too  Panuaeter  Ikfts 


TERM 

PARAMETER 

t  STATISTIC 

p VALUE 

tHBCISK^I 

u4> 

Pi 

2507 

05916 

Reject  Ho 

luQ) 

Pi 

1517 

05358 

Reject  Ho 

The  least  significsnt  fegression  coeCBdeot  was  ^2  which  was  significant  at  the  0.2358  levd  of 
confidence  which  exceeds  the  criterion  value  of  0.30. 


VJ.6  Model  Specification 

Residual  plots  against  the  indqiendent  variables  in  Appendix  D2  on  page  71  did  not  feveal  any 
padmns  that  would  indicate  a  nonlinear  lelatkxisliip. 

VJ.7  Distribution  of  the  Error  Terms 

The  hisiogram  on  the  same  page  shows  a  right  skew  due  to  observation  one,  wfaicb  encountered  test 
schedule  differences,  ^th  only  nine  observations  it  is  difficult  to  tell  if  the  errors  are  normally  distributed. 
A  normal  distribution  is  assumed  for  the  purposes  tff  this  model. 

V5.8  Outliers 

The  criterion  value  for  identifying  outliers  with  respea  to  X  for  this  modd  would  be  ^  = 
^  =  0.67.  Rrom  y^ipendix  D.3,  observations  three  and  nine  had  leverage  values  oi  05725  and  05724 
respectivdy,  exceeding  the  criteria.  These  observations  have  the  two  largest  fimciioo  point  values,  50J62 
and  32.36  reqxctively. 

The  criterion  value  for  identifying  outUers  with  respea  to  Y  fbr  this  modd  nshig  RSTUKNT  for 
this  modd  was  t(aaO.OS.  5)  «  2571  (21:630).  Only  observation  one  exceeds  this  criterkm.  Observation 
one  had  358  fimction  pointi  but  yd  took  three  weeks  to  oooqilete.  This  was  a  large  number  <ff  weeks  for 
the  small  number  of  function  pdnts,  due  to  teding  difficulties.  The  next  largest  RSTUDENT  was  only 
126,  not  a  significant  value. 
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VJ.9  Influential  Outliers 

Hie  outliefs  examined  for  influence  are  one.  three,  and  nine.  Obaervationa  one,  three,  and  nine  had 
KTITS  values  much  greater  than  one  (183,  3,56,  and  9  J7  reqwctivdy).  Observations  three  and  nine 
were  identified  as  an  extreme  outlien  with  reqxct  to  X.  If  they  were  to  be  removed  from  the  data,  the 
estimating  equatkm  would  change  significantly.  Observatioo  one.  the  outlier  with  leqiect  to  Y,  is  valid 
and  was  not  removed.  No  valid  reason  was  found  for  removirtg  any  die  outliers. 

VJ.IO  Collinearity 

In  Appendix  D.3  the  hugest  condition  number  was  13.  udiich  is  significanfly  less  than  die  criieiion 
value  of  10.  Both  tolennce  values  are  035,  so  if  IuQ>  were  r^iessed  against  u4>.  the  would  be  O.IS. 
Since  the  Rl^  x  model  is  0.60  which  is  much  huger  than  0.15,  colliiiearity  does  not  appear  to  be 
a  problem  in  this  model. 

VJ.ll  Prediction  Intervals 

The  prediction  intervals  for  teams  A,  B,  and  D  are  listed  in  appendix  D.4  on  page  73.  Most  of 
the  predictions  were  hi^Mr  dian  actual  values.  The  predictions  for  the  influeaial  poiids  three  and  nine 
were  very  close,  as  was  observation  two.  The  actual  values  for  observations  four,  five,  six,  and  eight  were 
widiin  their  predicied  intervals,  although  the  lower  end  of  their  imervals  were  n^ative.  The  actual  value  of 
observation  one  was  3.0  calendar-weeks  and  was  beyond  die  intervals  upper  boimd  at  13  calendar-weda. 

The  relationship  between  actual  schedule  response  and  predicted  is  ptoned  in  Hgnre  13  on  page  73. 
It  shows  several  close  predicted  schedule  reqxnses  at  low  levels  of  fonctioo  points  with  sonsewhat  worse 
predictions  than  Schedule  Model  One  in  Figure  12  on  page  69  at  the  influeniial  points. 

VJ.I2  Closing 

The  indicator  variables  produce  a  two-member  team  model  that  show  an  effort  reqxmse  at  a  rate 
sUghdy  more  than  three  times  that  for  the  one-member  model  This  indicates  diat  diere  is  schedule 
inefficiency  associated  with  two  programmen  coUaborating  on  a  project  as  apposed  to  one  programmer 
working  on  the  projea  when  m  equal  intcreqx  model  is  used.  This  second  schedule  model  doesn’t  seem 
to  predict  as  well  as  Schedule  Model  One  for  one  or  two-member  teams  qi  to  50  funedon  ponds.  This 
range  includes  a  gq>  from  10  to  32  fonedon  points  that  is  interpolaied  by  the  model  with  the  possibiliQr 
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that  a  noolinear  lelalionship  exuis  in  this  inteqwltted  regiop.  Additional  data  coUectioii  in  this  nwge  wiB 
leveal  the  cotainty  of  model. 

Vj6  Summit 


In  this  chapter  the  software  support  at  a  given  level  of  fimction  points  was  related  to  the  effort  and 
schedule  to  provide  that  siqipart.  The  effort  model  was  devdoped  widi  all  12  otiaeivaiioiis,  but  the  two 
schedule  models  were  developed  with  nine  obaervatioiis.  Three  schedule  obaervatioiis  were  ddeied  because 
they  were  a  result  at  special  causes  at  variation.  Most  of  the  itaponses  are  at  a  level  of  10  function  points 
or  less.  The  two  observations  at  32  and  50  function  pdnts  were  most  influential  and  resulted  in  a  model 
that  inteqxriates  the  reqxmses  to  requests  for  sdtware  nqiport  in  the  range  of  10  to  32  fhnctioo  points. 

The  use  of  indicator  variables  revealed  qtpuent  effort  and  schedule  inefBciency  when  two  program¬ 
mers  work  on  a  project  as  opposed  to  one.  The  inefBciency  was  more  pronounced  in  the  schedule  models 
than  the  effort  models.  The  prediction  iniervals  showed  a  tendency  of  the  models  to  overestimate  most  of 
the  responses  to  observed  levels  of  function  points.  The  effort  model  appun  to  be  very  significant  and 
predicts  reasonaUy  weD.  Most  (rf  the  actual  values  of  leqxMses  were  within  the  80  pereent  pretUciion 
interval.  Schedule  Model  One  predicts  fairly  weO  and  belter  than  the  second  model  Inqaoved  schedule 
estimation  will  require  more  data  fint  of  aU,  and  most  likely  additional  piediciori.  The  smaO  number  of 
observaiioos  prevented  a  conclusive  determination  at  the  distributioo  of  enor  teems.  With  the  eacqnion 
of  the  three  schedule  observations  that  were  ddeted,  the  remaining  observaiioos  were  subjea  to  typical 
variations  wiihhi  the  populJKion  of  interest.  Schedule  Model  One  will  be  used  to  predict  schedule  for  teams 
A,  B.  and  D  because  it  is  a  more  significant  lelationsh^  than  Schedule  Modd  T>ro. 
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VL  Conchuioa 


A  novel  technigne  has  been  developed  for  diiectly  the  effort  and  schedide  leqaiied  for 

Oracle  rtatahnic  softwwe  support  using  Mark  n  function  points  as  a  predicicr.  Hie  characterization  of  the 
size  of  die  software  sqiport  in  lenns  of  function  points  was  easfly  and  unanibignouaty  quantified  bMbre 
coding.  The  idatioMhip  between  the  observed  effort  and  schedule  responses  and  the  level  of  function 
ptnnts  was  significant  and  predictable. 

VLl  Mraswrenirnt  RcaMli 


V/.7.7  Sizing 

Hie  unamlnguous  mapping  of  Mark  n  function  poinis  to  Oracle  conqioneats  allowed  very  easy 
estimation  of  the  size  ot  the  software  sqiport  lequiied  before  coding.  After  analysis  and  design  were 
conqdeted,  the  programmen  were  able  to  exaedy  quantify  how  many  itqmts,  outputs,  and  entities  woidd 
be  added,  changed,  or  deleted  during  the  software  support 

VLl 2  Effort  and  Schedule 

Hie  measurement  effort  in  work-hours  was  stiaightforwanL  The  programmers  worked  on  the 
projects  with  a  varying  number  td  interrqitioos.  The  effort  measurements  were  aocinie  lo  one  tenth  of 
an  hour. 

Hie  measaements  of  schedule  hi  cakndar-wedcs  tended  to  vary  synificantly  more  than  the 
work-hours,  due  mainly  to  intemqitioos  from  emergent  demands  qx»  the  programmen.  Hie  achednie 
measurements  were  accurate  to  one  tenth  of  a  five-day  week,  or  about  half  of  a  day. 

VL2  Karimating  Rcsidia 


VI2.1  Effort 

Hk  relationship  between  a  given  kvel  of  fimetion  points  and  the  effort  reqionse  was  found  to 
be  very  significant,  with  an  qiparent  inefficiency  reflected  in  the  two-penon  response.  Hie  difference  is 
evident  in  the  nfy  coefficient  for  the  team  D  model  that  is  mote  than  twice  that  for  the  oonprogrammer 
model.  The  effort  model  to  within  two  digiis  of  precisioo  is: 

Ibam  :A,  B,  C  :  WorkHour*  =  0.54  +  2.0  x  «/p  (2S) 
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Iban  D :  WorkHourt  s  —10  +  4.2  x  ufp 


06) 


VI22  Schedule 

Hk  letattiafif  between  i  given  level  of  fonctian  pointt  nd  the  ichedule  leqionae  was  ftmnd  to  be 
tignificant,  with  an  qipnent  inefficiency  reflected  in  the  tw&penon  reqxmae.  Tlie  difference  is  evident  in 
the  nfjp  coefficient  fior  the  twoi>ogianimer  model  that  is  more  than  three  times  that  for  the  oneixogrammer 
modeL  The  sdiednle  nsodd  to  widiin  two  digits  of  precision  is: 

Ibam  A,  B  :  CatendarWeek$  =  0.99  +  0.038  x  ufp  (27) 

Tbam  D  :  C(dendarWeekt  =  —0.15  +  0.13  x  ufp  (28) 


The  validity  of  predictions  using  these  models  will  depend  qxn  whether  basic  conditions  in  the 
future  are  similar  to  those  during  the  period  of  observation  used  to  build  this  naodeL  Also,  since  the  modd 
is  baaed  on  observadonsiangmgiq)  to  50  function  poims.predictioos  above  that  levd  are  less  certain.  Tlie 
models  built  from  a  small  dam  set  and  were  very  dqxndent  upon  the  inflnentid  points.  Most  observatiaoB 
were  at  size  levels  less  than  10  function  points.  Tlie  influential  points  were  at  much  higher  levds  leaving 
a  gq>  that  is  inietpolaied  by  the  modd. 


VIJ.J  Measurement 

Regmding  the  data  collection,  a  point  that  needs  to  be  made  is  dial  the  dibit  and  schedule  modds 
predict  the  work-hours  cafendar-weeks  that  will  be  reported  m  the  reqnnae  to  die  size  kvd  measured 
in  function  pointt.  Iliis  is  not  to  imply  that  a  progrttnmer  would  ddflxcmely  provide  erroneous  data, 
but  rather  that  the  programmen  are  busy  supporting  die  mission,  and  are  Hkdy  to  qiend  as  Uale  thne 
as  possible  keeping  a  log  of  work-hours  qient  on  a  prcjecL  As  mentioned  earfier.  die  levd  of  sqipoit 
activity  was  lower  than  noimd,  which  mitigaiBd  any  incHnarinn  to  aacrifloe  data  ooOeetton  in  bvor  of 
meeting  a  schedide  and  resulted  in  the  excellent  quality  of  data  for  this  research.  However,  the  realities 
of  software  sitypoit  in  a  demanding  environment  with  tight  demlines  will  oettainly  threaten  the  quality 
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d  <kta  coUecied,  became  no  matter  how  much  Ae  maoagen  claim  that  collecting  data  is  of  panmount 
inqjoftanoe.  the  pngnmmen  know  diat  the  bottom  line  it  delivering  the  software. 

Ihe  tneasuremmit  d  the  sue  of  the  software  nqjpost  was  bated  on  the  programmer’s  oompleied 
analysit  and  design.  An  aheraative  would  be  to  use  inftmationavaiiaUe  after  only  the  analysis  is  oompleie 
but  not  the  design.  just  the  analysis  completed,  it  would  be  unreasonable  to  ask  a  prognmmer  how 
many  trigger-steps  wiU  be  added,  dianged,  or  deleted,  but  not  unreasonable  to  ask  bow  many  taUe-based 
blocks  win  be  affected  by  a  software  suppoft  request  This  early  count  of  entities  could  be  used  to  either 
estimate  the  eventual  number  of  inputs  and  outputs  that  win  be  affiscted,  or  to  direcdy  estimaie  efRxt  and 
schedule  fiom  the  number  of  additions,  changes,  and  deletiona  of  entities.  Also,  since  only  one  project 
had  more  than  one  transactian  mvoNed,  a  potential  ftctor  could  be  the  number  of  transactions  stgipotted 
in  a  project  This  count  would  be  e^ieciany  significant  as  a  predictor  erf  effort  and  sdiedule  with  increased 
testing  due  to  the  interactiona  between  many  transactions.  The  technical  complexity  adjustment  (TCA) 
was  held  constant  for  all  the  projects.  There  may  be  enough  differences  within  the  SCV  eovirooment 
to  justify  vaiying  the  TCA. 

The  mappings  ftom  Oncle  components  to  Mark  n  fimetion  points  seem  to  characteriae  the 
functionality  very  well,  but  may  not  be  perfiect  Specifically,  S(^*Fonns  and  SQL*Reports  are  dUfoent 
software  development  tools.  The  assunquion  is  dnt  there  is  a  high  correlation  between  the  mappings  of 
each  language’s  conyonents  to  Marit  n  function  points.  ^Kfitb  such  a  small  study,  it  is  not  feasible  to  lest 
this  assumption.  A  possibility  for  further  research  would  be  to  define  many  competing  mapping  strai^ies, 
and  coUea  data  on  afi  projects  using  afi  the  mapfrings.  Then  for  S(^*Fonns  and  S(^*Reports  projecu 
that  required  the  same  amount  of  effort  or  schedule,  find  out  which  mapping  strat^ies  count  them  at  the 
same  level  of  fimetion  points.  This  would  enhance  the  usefulness  of  the  weights. 

In  this  research,  the  size  was  weighted  using  Symons’  industry  average  set  The  size  of  the  software 
siqtport  could  be  tabulated  by  transactions,  itqatts,  entities,  and  outputs  that  were  added,  changed,  or  deleied 
as  shown  in  ThUe  8.  A  possibility  for  fidure  research  would  be  to  ran  a  multiple  icgressfon  on  the  inputs. 
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entities,  and  outputs  that  would  provide  a  set  of  weights  local  to  SCV.  Another  possibility  would  be  to 
perfonn  a  multiple  regtession  on  the  count  of  weighted  additions,  changes,  and  deletions  (ACD). 

The  sizes  of  the  projects  in  this  research  were  sufficiently  smaO  that  it  was  not  difficult  to  estimate 
the  exact  number  of  function  points  that  would  be  supported.  But  with  luger  projecu.  the  differaice 
in  estimated  and  actual  function  points  will  become  significant.  A  possible  remedy  is  to  have  automatic 
change  detection  using  a  before  and  after  ftmction  ptfint  count  The  data  coUectioo  program  in  ^ipendix 
H  currently  provides  sizing  by  analogy,  and  with  some  modifications  could  also  be  used  to  track  changes 
to  the  baseline  of  ftmction  points  through  time.  The  program  could  be  elevated  fiom  the  status  of  a  small 
prototype  to  an  operational  sizing  and  estimating  tool  using  Pro* Ada,  an  Oracle  pnxbKt  diat  provides 
datahasft  binding  to  an  Ada  program  (22:S0-51).  Pro*Ada  would  allow  direct  access  to  the  database  fiom 
the  data  ctdlectioo  program.  Another  consideration  is  to  revisit  the  ponMlity  of  using  S(H'*Repo>ts  as  the 
data  collection  software.  The  data  dictionafy  rqwrt  program  already  accesses  the  Oracle  components.  The 
most  convenient  agpccL  at  using  the  data  dictionaiy  to  count  ftmctioo  points  is  that  the  Oracle  components 
that  are  mapped  to  the  ftmction  points  have  names.  These  names  could  be  viewed  as  the  software  baaeWnc. 
which  means  dua  the  entire  baseline  could  be  viewed  in  terms  of  named  ftmction  poims  as  in  Appendix 
F  on  page  75. 

Currently  SCV  does  not  make  use  of  the  more  advanced  capdiility  of  version  3.0  to 
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imbed  procedures  into  the  fonns.  Should  that  cq)ability  be  tapped,  the  cunent  method  of  oountiiigfuiiciiafi 
points  would  likely  lose  some  of  the  power  to  explain  variatioo  firom  the  effort  and  schedule  mean  response 
to  a  given  level  of  function  pmnts.  One  possibility  would  be  to  include  an  algorithmic  parameter  to  the 
three  defined  by  Symons,  in  the  same  manner  that  Jones  added  a  sixth  paiameier  to  AOxecfat’s  original 
five  parameten.  A  fourth  parameter  added  to  Made  n  fimetioo  pefints  to  measure  algorithmic  cooqriexity 
would  create  a  method  sufficiently  different  that  it  would  warrant  the  designation  Mark  m. 

Since  this  study  was  based  on  relational  database  software  support  with  a  4GL,  k  was  very  easy  to 
adqit  Mark  n  ftmetion  points  to  the  software  support  With  a  3GLiikeCOB(X<  it  is  not  so  convenient  and 
would  probddy  entail  the  accumulation  of  a  lot  rules  like  Dreger’s  and  Jones’,  unless  the  development 
methodology  was  focused  on  inputs,  outputs,  and  entities.  This  would  be  easier  if  a  technique  known  as 
Hierarchical  Input  Process  Omput  (HIPO)  design  was  prevalent  in  the  organization,  from  design,  through 
configuration  management  to  documentation.  Instead  of  programmers  arbitrarily  creating  modules  in  an 
ad  hoc  manner,  but  rather  designed,  documented,  and  managed  the  mothiles  as  a  configuratioo  of  Mark  n 
fimetion  points,  a  3GL  project  might  be  as  easy  to  size  as  die  projects  in  this  study.  If  an  organization 
had  both  a  3GL  and  SQL*Rirms  3.0,  the  Mark  n  function  poinu  ooundog  rales  they  establish  for  the 
SOL  could  also  be  spidied  to  any  imbedded  procedures  in  SQL*Farms.  Any  of  these  suggested  changes 
should  be  evaluated  for  thdr  usefulness,  and  a  possibility  is  using  Boehm’s  10  criteria  for  evalnatiqg  a 
software  cost  model:  definition,  fidelity,  objectivity,  constructiveness,  detail,  stability,  scope,  ease  of  use, 
prospectiveness,  and  parsimony  (6:476). 


V7J.2  Estimating 

The  single  predictor  was  created  by  using  Symons’  Industry  Average  Set  of  weights.  This  limits 
the  potential  explanatory  power  in  mult^ile  predictors  thbulating  the  number  of  additions,  changes,  and 
deletions  of  function  points.  As  a  case  in  point,  the  two  influential  observafions  at  32  and  SO  fiaiction 
points  appear  to  indicaie  a  negative  relatroosh^)  with  effort  when  pkNted  alone  as  in  Figure  9  When  the 
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Figure  9.  Influential  Points 


ocher  observatioiis  are  added  along  with  the  regressioa  Ihie  as  in  Figure  10,  it  shows  that  the  obaervatioiis 
arc  valid  although  a  couple  of  standard  deviadons  out  from  the  regression  line  at  their  levels.  Upon  closer 
examination,  the  observation  at  32  function  points  just  higjpens  to  be  entirely  changes,  and  the  one  at  SO 
function  pmnts  is  entirely  additions.  There  is  potential  for  gaining  additional  eiqrianaiovy  power  from  the 
observations  by  perfomiing  a  muh^le  r^resskm  based  on  three  factors:  additions,  changes,  and  deletions 
of  function  points. 


Another  area  lacking  data  is  the  reqtonse  of  teams  of  three,  four,  or  more  peofde.  As  team  memben 
increase  arithmeticany,  the  lines  of  oommunicatioo  among  them  increase  geometrically,  b  would  be 
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intetesting  investigate  Putnam’s  assertioa  tiuu  die  proUem  solviog  response  ttf  groqis  of  four  or  more 
peoide  are  essentially  the  same  024:216). 

Currently  computer  lesouree  usage  by  individual  is  unknown  the  accounting  infonnatioa 

is  not  activated,  and  because  usen  and  progranuners  log  on  with  a  single  g^oap  identification  account  If 
accounting  information  were  availaUe  team  and  project  it  could  be  used  to  derive  date  and  times  to 
firee  ptogmmmers  fiom  schedule  data  coUection. 

Hunqihrey  outlined  a  method  of  using  time  series  to  for  a  progiammer’s  learning  curve 

and  delect  when  the  software  development  process  has  reached  a  stable  state  (17:203).  A  proMem  widi 
his  method  is  diat  it  is  based  on  LOCs  and  invites  its  paradoxical  effects  on  software  economics.  If 
Hunqihrey’s  method  were  based  on  a  truer  measure  a[  software  such  as  function  points,  the  process  could 
be  brought  under  statistical  control  with  a  truer  sense  of  continual  improvement. 

Another  benefit  of  using  function  points  is  to  study  the  effect  of  training.  Several  months  oi  team 
observations  could  be  collected,  then  the  training,  foQowed  by  another  run  of  observations.  If  die  training 
was  effective  it  might  show  iqi  as  increased  efficiency  in  siqiporting  strftware  requests. 

The  schedule  response  is  less  significantly  related  to  function  points  than  the  effort  reqxmse.  This 
is  not  surprising  since  by  definition  worit-hours  are  only  the  hours  qrent  working  on  a  particular  project, 
while  calendar  weeks  accumulate  far  as  long  as  the  programmer  work-*  on  the  project,  including  whatever 
inteinqitioiis  delay  the  project  So,  a  team’s  sdiedule  response  is  likely  to  be  dependent  upon  other  factors 
in  addition  to  function  points.  One  possilnli^  is  defining  a  factor  that  reliably  characterizes  a  worit  order’s 
true  priority  to  the  organization.  Said  in  another  way.  to  erqdain  wVHrimiiii  variation,  define  a  factor  that 
measures  the  likelihood  of  a  projea  being  preempted  in  favor  trf  eroergent  demands  qxm  the  organization. 
Bob  Esterling  created  an  elaborate  set  of  metrics  based  on  the  intetnqitions  that  retard  programmers’ 
productivity  (13:164). 

There  is  also  a  commercial  scdtware  sizing  and  estimating  product  called  Before  You  Leap  (BYL) 
diat  uses  Mark  n  function  points  (33:177).  It  was  not  available  far  this  research.  It  mr^  be  woidi  lookii^ 
into  far  adqrtation  to  SCV’s  envirooment.  since  it  is  now  dear  that  there  is  a  significant  rdationship 
between  Mark  n  fanction  poinu  and  effort  and  sdiedule,  for  the  SCV  envirouneaL  Another  possibility  is 
to  create  a  dafabase  at  AFTT  for  cdlecting  size,  effort,  and  schedule  measureuMats  from  mariy  Oracle  sites 
throughout  the  Air  Force.  The  indusion  at  many  sites  as  a  study  to  follow  this  research  would  definitdy 
require  that  the  environmental  factors  te  added  to  the  values  coOected.  The  benefit  would  be  to  create  a 
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sirftware  support  measurement  and  estimating  system  tailored  not  ordy  to  Oracle  systems,  but  to  Air  Faroe 
applications  and  procedures  as  well. 

VL4  Software  Quality 

Many  lexttmoks  vainly  attempt  to  define  stdtware  quality,  but  fiieie  are  two  books  on  qnaUqr 
wordi  adapting  to  software:  Robert  Pirsig’s  classic  analysis  of  quality  (23:100)  and  Dr  Demiqg’s  idea 
of  operational  definitions  (11:276-296).  Both  enqtbasize  a  thoughtful  qiptoach  to  quality  based  on  a 
precise  understanding  <rf  flmctionality.  Function  pmnts  can  provide  a  meaningful  measure  (tffiBKtion>bosed 
stdiware  quality,  that  can  not  only  provide  a  means  ct  sizing  and  estimating  stdtware  support  required,  but 
can  also  take  advmitage  of  scientific  methods  of  management  that  have  been  perfected  in  other  discqdines. 

In  micro-economics  for  instance,  a  firm  can  minimize  its  losses  by  operating  at  a  level  where 
maiginal  cost  is  etpial  to  marginal  revenue  (14:259).  This  is  also  related  to  the  concept  oi  oonqdementary 
slackness  in  management  science,  and  Barry  Boehm  described  a  similar  method  called  marginal  analysis 
(6:209-210).  In  this  research,  ^ort  and  schedule  n^tession  lines  were  developed,  and  each  line  has  a 
slope,  which  is  the  marginal  cost  (tfsiqjporting  function  points.  The  marginal  cost  in  hours  or  weeks  can  be 
converted  into  dollars.  The  problem  is  deriving  marginal  revenue  in  a  government  (or  nonprofit)  operatioo. 

Revenues  can  be  realized  with  a  recent  innovation  in  the  Did>  called  Defense  Business  Operating 
Fund,  (DBCXO.  It  is  an  attempt  to  eruUe  government  organizations  to  market  their  products  within  the 
government,  and  actually  receive  revenue.  In  fact,  one  software  organization  at  Gunter  AFB,  AL  b 
devdoping  software  atul  marketing  it  within  the  DoD  ^:1).  With  this  measure  of  revenue,  it  is  possible  to 
derive  marginal  revenue  for  function  points,  allowing  the  organization  to  minimize  its  losses  by  operating 
at  a  level  cf  function  points  where  marginal  cost  is  equal  to  marginal  revenue. 

Even  without  the  private  sector’s  convenient  common  denominaior  in  the  dollar,  there  ate  ways  to 
achieve  continual  inqirovement  of  scrftware  quality  based  on  fimction  points.  A  simple  example  might  be 
the  number  of  LOCs  per  function  point  A  measure  of  quality  mi^  be  the  fewer  LCX^  per  function  point 
the  better.  This  ttf  course  may  encourage  poor  programming  practices  that  leads  to  error-prone  software.  A 
more  sophisticaied  definition  of  how  to  deliver  software  functions  should  be  based  on  a  precise  qiedfication 
a  programming  style  guide,  as  well  as  a  means  for  scoring  the  conqriiance  wkh  the  style  guide. 


Mdi  the  additional  information  acquired  by  measving  software  functionality  in  terms  of  function 


points,  managers  can  achieve  greater  contnri  the  software  snppoit  process  through  greater  knowledge 
ot  the  conditioned  reqionses  of  the  process.  As  many  authors  have  noted,  we  cannot  manage  what  we 
cannot  measure! 
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Appeadh  A.  ObacrvitkM 


•  A3:  individual  enlisted  progranunen 

•  C  individual  coniiactor 

•  D:  team  of  two  enlisted  fMOgranunen  (A  and  B) 
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A.1  FtrcqucBcy  Plots 
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AJ  Effort  Scatter  Plot 
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AJ  Sckcdak  Scatter  Plot 


Plot  of  llllK8*tlPP.  Symbol  ia  vaXno  of  tBlM. 
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Appcadlz  B.  Effort  Model 
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Appeadix  C.  Schcdale  Model  Oae 


C.1  ANOVA  omI  PvoMcter  Fatiartee 


Modal:  nr 

Dapandant  Variabla:  WEKirs 


Souxoa 


Modal 
Bzror 
C  Total 


Analysis  of  Vaziaaoa 

Ssa  of  Main 

DT  Bqoazas  Squaza 


3  11.20229  3.73410 
5  5.04660  1.00932 
8  16.24889 


r  Valna 
3.700 


Pzob>r 

0.0965 


Root  MSB 

Dap  Maan 

C.V. 


1.00465  R-squasa  0.6894 

1.51111  Adj  R-aq  0.5031 

66.48415 


Pazaaataz  Bstlawtas 


Variabla  DF 

ZMTBRCXP  1 

OTP  1 

I  1 

IOTP  1 


Paraaatar 

Bstiaata 

0.987992 

0.038427 

-1.142614 

0.089399 


Standard 

Brror 

0.50596367 

0.02378450 

0.97807916 

0.04998601 


T  for  BO: 
ParsaaitarM) 

1.953 

1.616 

-1.168 

1.788 


Prob  >  |T| 

0.1083 

0.1671 

0.2954 

0.1337 
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C2  Model  SpecUcatta 

Plot  of  mSZD*ms.  fl}i«>ol  la  Talno  of  TBPM. 


fSBSXD  Roaldoal  Com.  Com. 


Midpoint 

1 

Faoq 

Pzoq 

Poxoant 

Poxoont 

-1.2 

1 

1 

1 

1 

11.11 

11.11 

-0.4 

1 

1  ****j^****B****l>****I) 

I 

4 

5 

44.44 

55.56 

0.4 

1 

3 

• 

33.33 

•t.io 

1.2 

1 

1 

0 

• 

0.00 

•6. to 

2.0 

1 

— — -+ - -+ — — + 

1 

0 

11.11 

100.00 

12  3  4 

rsaqnaney 
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CJ  LilMBtial  Oadkn  aad  ColiMarity 


0B8  HAT 

1  0.21083 

2  0.17082 

3  0.98297 

4  0.19586 

5  0.21083 

6  0.22889 

7  0.47126 

8  0.53050 

9  0.99824 


Variabl* 

nmcacEP 

xjn 

X 

IOTP 


MTDD 

OTIT8 

5.47349 

2.82908 

-0.36220 

-0.16428 

0.46822 

3.55722 

-0.61188 

-0.30197 

-1.04699 

-0.54116 

-0.06266 

-0.03414 

-0.39329 

-0.37130 

0.39329 

0.41806 

0.39329 

9.36903 

DP 

Tolaranea 

1 

1 

0.77251197 

1 

0.52753464 

1 

0.44932603 

Colllnaarlty  Diagnostics (iatazoapt  adjustad) 


Condition  Vaz  Pzop  Vaz  Pzop  Vaz  Pzop 


)Z 

■Igan^alna 

Itaabaz 

OTP 

I 

IOTP 

1 

1.77089 

1.00000 

0.0630 

0.1093 

0.1240 

2 

0.96712 

1.35318 

0.5892 

0.1428 

0.0003 

3 

0.26199 

2.59989 

0.3478 

0.7480 

0.8757 
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PradktiM  latervals 


Ikbk  11  shows  the  predicted  response,  qjper.iDd  lower  bound  of  tbe  80  peroentpredictkiiiniervaL 
Hie  actual  calendar-wedcs  for  each  observation  is  shown  in  boldCree  relative  to  the  predicted  values  and 
the  bounds. 


Ihble  11 

M  Percent  Prediction  Intervals  for  Schednle  Model  One 


OBS 

Lower 

Actual 

ftedicted 

Actual 

Upper 

Actual 

1 

-03786 

1.1256 

23297 

33 

2 

-0.1176 

IjO 

13646 

23467 

3 

1.0883 

2.9332 

3Ji 

4.7780 

4 

-03068 

OjS 

1.1893 

23855 

5 

-03786 

03 

1.1256 

23297 

6 

-0.4519 

lA 

1.0618 

23754 

7 

-0.9810 

03 

03152 

2.0113 

8 

-13011 

03030 

03 

13071 

9 

2.3968 

3.9818 

43 

53669 

Plot  of  Predicted  vs  Actual  Sdiediiie  (1) 


Figure  12.  Schedule  Model  IVro  Predicted  Actual  Sdiedule 
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Appcadlx  D.  Sdbedak  Model  IVro 


D.1  ANOVA  and  Parameter  Estimates 


Souxe* 


Modal 
■rror 
C  Total 


or 

2 

€ 

8 


Aoalyala  of  Vaxiaskoa 


8uat  of 
Squaraa 

9.82482 

6.42407 

16.24889 


Maaa 

Squaxa 

4.91241 

1.07068 


r  Valua 
4.588 


Root  MSI 
Dap  Maan 
C.V. 


1.03474 

1.51111 

68.47514 


R-aqoaza 
Adj  R-aq 


0.6046 

0.4729 


Paraamtar  latismtaa 


Vaxiabla  DP 


Parwimtar  Standard  T  for  BO: 

latismta  Brror  Paraaaitar*0  Prob 


XMTIRCIP  1 
DPP  1 
IDPP  1 


0.682226  0.44597194 
0.046844  0.02334585 
0.049292  0.03741901 


1.530 

2.007 

1.317 


Prob>P 

0.0618 


>  l»l 

1.1770 

1.0916 

1.2358 
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D J  Model  Spcdfcatioo 


Plot  of  msix>*vua.  Symbol  !•  mmlvm  of  TBMC. 


I 

3  + 


2  * 


m 

1 

d 

u 

1 


1  •¥ 


0  + 


-1  + 


0.5 

1.0 

1.5 

2.0 

2.5 

3.0 

3.5 

THBSID 

Rooldual 

Prodictod  Valuo  of 

Pxwi 

Om. 

WToq 

1 

Porcoat 

Porcont 

-1.2 

1 

1  ****x) 

1 

1 

11.11 

11.11 

-0.4 

1 

1  ****J^*«4 

t*B****B*4 

t**B****D 

5 

€ 

55.56 

66.67 

0.4 

1 

1 ****B****0 

2 

8 

22.22 

88.89 

1.2 

1 

1 

0 

8 

0.00 

88.89 

2.0 

1 

1 

1 

2  3 

- 1. 

4  5 

1 

9 

11.11 

100.00 

Pxoquoney 
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D  J  I^ueatial  Outliers  aud  CoBincarity 


088 

HAT 

RSTOD 

DTITS 

1 

0.21083 

5.47349 

2.82908 

2 

0.17062 

-0.36220 

-0.16428 

3 

0.98297 

0.46822 

3.55722 

4 

0.19586 

-0.61188 

-0.30197 

5 

0.21083 

-1.04699 

-0.54116 

6 

0.22889 

-0.06266 

-0.03414 

7 

0.47126 

-0.39329 

-0.37130 

8 

0.53050 

0.39329 

0.41806 

9 

0.99824 

0.39329 

9.36903 

Varlabla  DF  Tolaranoa 


ZMTBSCBP  1 

UTP  1  0.85055734 

inrp  1  0.85055734 


Collinaarity  Diagnostics  (intacoapt  adjusted) 


Condition  Var  Fsop  Vas  Prop 
Muabas  BigsnTslus  Musbss  DFP  lUFP 

1  1.38658  1.00000  0.3067  0.3067 

2  0.61342  1.50346  0.6933  0.6933 
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D4  PredktioB  Intervals 


IkUe  12  shows  the  predicted  fe8ponse,q)per,  and  lower  boond  of  the  80  percent  predictiacintervd. 
The  actual  calendar-weeks  for  each  observation  is  shown  in  boldface  rdadve  to  the  predicted  values  and 
the  bounds. 


Thbk  12 

SO  Percent  Prediction  Intervtfs  for  Schednle  Model  IWo 


OBS 

Lower 

Actual 

ftedicted 

Actual 

Upper 

Actual 

1 

•0.6542 

0.8499 

23541 

33 

2 

•0.3408 

IJI 

1.1413 

2.6234 

3 

1.2086 

3j0 

3.0535 

43983 

4 

-OJ68S 

0.6 

0.9277 

2.4238 

5 

-0.6542 

OJ 

0.8499 

23541 

6 

-0.7415 

0.7722 

li) 

23858 

7 

•0.3102 

02 

1.1860 

2.6821 

8 

-0.4777 

OjS 

1.0264 

23305 

9 

2.2082 

3.7932 

4JI 

5.3782 

AppMdix  E.  FGREP 


E.1  FP2.RE 


The  text  file  FP2  JtE  cootaiiis  the  key  strings  for  the  file-oriented  r^iibr  expression  paner,  POREP, 
to  search  for  in  a  data  (Uctionafyrqxxt  produced  by  an  Oracle  pcognmfonn.docjpL  POREP  is  invoiced  by 
the  Digital  EquqNnent  Coip.  Oonunand  Language  file  REDUCE.OOM  in  the  next  section.  The  contents 
of  FP2JtE  are  as  follows: 

TITU: 

TZPi: 

STSP  - 

rixiD 

Block 


E.2  REDUCE.COM 


The  fisUowing  DCL  file  prompts  the  analyst  for  information  about  a  particular  SER  and  invokBS 
POREP  to  search  for  Oracle  SQL*Forms  conqxments  that  are  mapped  to  Marie  n  fimetioo  pants  as  defined 
in  OugNer  Three,  by  the  program  listed  in  Appendix  H  on  page  100. 

$  riltfouBd  >  "" 

$  rOBM  >  "a” 

$  SIR  >  "n" 

$  L00P2: 

$  inqulan  p2  "Nhat  is  ths  8BB4  (1  to  5  digits)  " 

$  lOOPl: 

$  iaquiss  pi  "Bntsr  fils  nams  of  .LI8  fils,  witbont  .LIS  past  " 

$  dsfins  sysfioutput  'PI' .fp2 
$  fgxsp  -f  fp2.xs  'Pl'.lis 
$  dssssiga  sysfioutput 
$  rsa  'Pl'.lis  'P1'.'P2' 

$  dir/siss/dsts  'PI'* 

$  inqoixs  POm  "Do  you  haws  anothsr  fils  ?  (y/a)  ” 
fi  if  POSM  .sq.  "y"  thsB  goto  LOOPl 
$  iaquixs  8XR  "Do  you  haws  aaothsr  SBR  f  (y/a)  " 

$  if  SIR  .sq.  "y"  tbsa  goto  L00P2 
$  Dons: 
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Appcadh  F.  SQL*Fonu  lapals,  EatWci,  Oatpati 


The  fidlowing  listing  is  the  result  of  REZ>UCE.COM  semmg  a  data  dictnoafy  report  and  it 
rquesoits  the  portion  of  the  SCV  baseline  from  a  S(^*Fonn  (Mafc  n  Ttaisactioo)  called  Admission. 
Within  the  listing  are  the  names  of  the  function  points.  For  instance  towards  the  end  of  the  listing, 
one  particular  trigger  step  (Marie  n  hqiut)  can  be  uniquely  distinguished  fiom  an  the  othen  in  the  entire 
baseline  by  conqtletly  qKdfying  its  fonn.  Mock,  field,  and  trigger  ADMISSKW,  FERSCXl,  SSAN, 
KEY-PRVFLD,  STEP  1. 


TITLE:  ADMISSION 

TYPE:  CHECK  MANNING  CODE  TRG 
STEP  -  1 

TYPE:  CLEAR_DETAILS_TRG 
STEP  -  1 

TYPE:  KEY-CLRBLK 
STEP  -  1 

TYPE:  KEY-CREREC 
STEP  -  1 

TYPE;  KEY-DELREC 
STEP  -  1 

TYPE;  KEY-DOWN 
STEP  -  1 

TYPE:  KEY-NXTREC 
STEP  -  1 

TYPE:  KEY-NXTSET 
STEP  -  1 

TYPE:  KEY-PRVREC 
STEP  -  1 

TYPE:  KEY-SCRDOWN 
STEP  -  1 

TYPE:  KEY-SCRUP 
STEP  -  1 

TYPE:  KEY-UP 
STEP  -  1 

TYPE;  PERSON_TRG 
STEP  -  1 
STEP  -  2 
STEP  -  3 

TYPE;  PRE-INSERT 
STEP  -  1 

TYPE:  RESIDENT_TRG 
STEP  -  1 
STEP  *■  2 

Block  1  :  PERSON 

TYPE:  KEY-CLRREC 
STEP  -  1 

TYPE:  KEY-ENTQRY 
STEP  -  1 

TYPE:  KEY-EXEQRY 
STEP  -  1 
FIELD  1  :  SSAN 
FIELD  LENGTH:  11 

TYPE:  KEY-PRVFLD 
STEP  -  1 
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Appeadix  G.  Dirta  Dktioaarj  Pragran 


RBI  Thia  ATZT/SCV  RPT  application  pcovidaa  haxdeepy  docuaantation 
RBI  for  apaelfle  8QL*rORII8  applieatioaa  using  tba  Osaela  dictionary. 
RBI  updated  10/90  MB 

PBI  **************************************************************** 


*****  Daclara  ZAPAPP  table  related  ▼arlables  ***** 
t****  APPIiZCATZON  ibvbl  zmposmaxzoh  varzabzxs 
.I>BCIARB  APPZD  99999  .RBM  APPZiZCATZOH  ZD  MDMBBR 

.DBCZARB  APPONMER  A30 
•  DBCZARB  APPKAMB  A30 
.DBCZARB  APPTZTU  A80 
.DBCLARB  TODAY  A9 


RBM  APPZJGATZOH  OMHBR'  8  ORACLB  n8BR  MAMB 
RBM  BBORT  APPLZCASZOM  MAMB 
RBM  TZTZJC  D8BD  lOlt  MOM  ZAP  MBHU 
RBM  DATS  or  RBPORT  GBMBRATZOM 


Declare  ZAPBZX  table  related  variables  ***** 
BLOCK  LBVBL  ZMTORMATZOM  VARTARLB8 


.DBCLARB 

BLKMAMB  A30 

.RBM 

.DBCLARB 

BLKDB8C  A60 

.RBM 

.DBCLARB 

BLK8BQ  999 

.RBI 

.DBCLARB 

BLKDMQKBY  A3 

.RBM 

.DBCLARB 

BZJCTHAMB  A€1 

.RBM 

.DBCLARB 

TDB8CRZPT  A€0 

.RBM 

.DBCLARB 

BLmORBC  99 

.RBM 

.DBCLARB 

BLKMOBOr  999 

.RBM 

.DBCLARB 

BLKBLZW  99 

.RBM 

.DBCLARB 

BLKLMRC  99 

.RBM 

or  BLOCK  ZM  APPL 


HOLL-OITRL  BLCK 


RBM  *****  Declare  all  ZAPOaMNBMT  table  related  variables 
RBM  Priaary  Kay  values  need  not  be  declared  again. 
.DBCLARB  CMTTBKT  A80  .RBM  OC8BIBMT  LZMB  OP  TEXT 

.DBCLARB  BOZLPLAXB  A80  .RBM  BOZLBRPLATB  MAMB 


RBI  *****  Declare  all  ZAPTZD  table  related  variables  ***** 

PBI  *****  rZBZD  LBVBL  VARZABU8 
.DBCLARB  rZJDMAMB  A30  .RBM  rZBZD  MAMB 

.DBCLARB  rU>8BQ  99  .RBM  8BQ0BMCB  MCMBBR  OT  FZBLD  ZM  BLOCK 


.DBCLARB  nOTZPB  A7  .RBM 
.DBCLARB  nDLBM  999  .RBM 
.DBCLARB  riDQLBK  999  .RBM 
.DBCLARB  rZDBTAB  A3  .RBI 
.DBCLARB  rLDKBT  A3  .RBI 
.raCLARB  rLDCRTLO  Afil  .RBM 
.DBCLARB  rZDDIXT  A80  .RBM 
.DBCLARB  riDOZBP  A3  .RBI 
.DBCLARB  IXDPASB  099  .RBM 


rZBLD  DAXAT7PB 
rZBZD  ZBHOTB 
QUBRX  UDRSZH 

Y  m  DATARA8B  FZBLD 

Y  ■  rZBID  PART  or  PRZMARY 

rZBZD  MAMB  YROM  WHZCB  TO  OOTY  BBT 
DBTAOLT  VALDB 
T  «  DZ8PLAYBD  rZBLD 
[rXJWAGB]  PAQB  MOMBBR 
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DTIAKK  nCLm  099 
naCTAKK  nDPROMPT  ASO 


m  [ru>Lzn]  umb 


■  DBCTAKB  IXDBITlIt  A3 
.DBCZARB  rLDQDIiar  A3 
.HBCTABB  nDUPOATI  A3 
.PICIABB  nDOroilUL  A3 
.DBCZARB  rUMMID  A3 
.raCLMB  rZCriZBD  A3 
.DBCZABB  rXCSKIP  A3 
.OICXAItB  m>BIOB  A3 
.DBCXARB  nDADfOBlV  A3 
.racun  riDDPPBR  a3 
.PBCIAKK  IXDLOVC  A80 
.naCTABB  nCAOIf  A30 
.DBCTABB  IXDBZ  A30 

.nan ABB  iij>hblp  aso 

.DBCXABB  IXDDB8CBXPT  A€0 


.BBM  T  «  BBTBBBBIA  FIBLD 
.BBI  X  «  OnBBTABIA  FIBU) 

.BBM  T  «  qPTlATBBLB  XIBID 

.BBM  X  >  PPDAXBBBU  XT  MULL  XIBLD 

.BBM  X  -  MBMDAfOBX  FIBU) 

.BBM  X  ■  rzxBD  UEHOra  riBXD 
.BBM  X  •  SKIP  SO  HBBT  PXBID  BBBH  POLL 
BBM  X  >  MO  BCaO  OP  BBXBD  PAZiDBS  SO  STBBBM 
BBM  X  >  AOSO  DI8PXAX  BBLP  OH  PIBU)  BRRX 
.BBM  X  X  CCMVBBS  SO  OPPBR  CASB 
.BBI  MAMK  OP  SBB  LI8S-0P-PAU1B8  OOUMM 
.BBM  urn  VAIOB 
.BBI  BXGB  VAXiDB 
.BBM  rXBZO  BBLP  MBBBAGB 
.BBM  rZBIO  SB8CBXPSX0M 


.BBM  *****  Dttclar*  lAPSBIGGBR  r«lat«d  TariablM  ***** 

.BBM  *****  SBIGGBB  VBBIABLB8 

.naCTABB  SBIORPB  A30  .BBM  SXPB  OT  SBIOGBB,  MACBO 

.DBCXABB  SBIGDB8C  A20  .BBM  SBZOGBB  DB8CBXPSZ0H  POB  BBS  DI8PXAX 

.DBCXABB  SBIGBIDB  A3  .BBM  X  ■  DZ8PXAX  SBZOGBB  ZM  BBX  DZ8PXA 


.BBM  *****  DBclaM  ZAPSBG  (Sriggar  atop)  xalatad  ▼aciablaa  ***** 

.BBM  *****  SBZOGBB  VABTABTA8 

.DBCXABB  SBC8BQ  9999  .BBM  SBZOGBB  SSBP  MOMBBB 

.DBCXABB  SBGXABBL  A30  .BBM  8SASBMBMT  XABBL 

.DBCXABB  SB0CDB8  A1  .BBM  X  >  MAZMTAZM  A  8BPABASB  CPB80H 

.DBCXABB  SBGMVB  A1  .BBM  X  ■  ABOBX  SBZOGBB  ZP  8SBP  PAZXA 

.DBCXABB  SB6ZMX  A1  .BBM  X  ■  BBVBBBB  KBSUHM  OOOB 

.DBCXABB  SBGBOXJ.  A1  .BBM  X  >  BBSDBM  PAZXABB  MBBM  ABOBXZMG  SBZG 

.DBCXABB  SB68XAB  A30  .BW  SD0CB88  XABBL 

.DBCXABB  SBOrXAB  A30  .BBM  lAZXXIBB  XABBL 

.DBCXABB  SBOMSG  ASO  .BBM  MB88AGB  DBLZVBBBD  OH  PAZLORB 


.BBM  *****  Daelaxa  ZAP8QLSXS  calatad  Taxiablaa  ***** 

.BBM  *****  8QL  SBXS  VABTABXA8 

.DBCXABB  SQSMO  999  .BBM  SBZOGBB  MDMBBR  A8SZGRBD  PBOH  ALL  XAVBLS 
.DBCTABB  SQSSBBS  ASO  .BBM  SBXS  POH  ALL  SBZOOBBS 

.BBM  *****  Daelaxa  ZAPMBP  tabla  aalatad  Taxiablaa  ***** 

.BBM  *****  MAP  SCBBBM  VBBTABTA8 

.DBCXABB  MBPPAOB  999  .BBI  BOZLBBPXASB  PAQB  Ml— PB 

.DBCXABB  MAPLZMB  999  .BBI  BOZLBBPXASB  LZHB  HOMBBB 

.DBCXABB  MAPSBXS  ASO  .BBI  BOZLBBPXASB  SBXS 

.XBCXABB  PAOBCMS  999  .BBM  OOUHSBB  POH  BOZLBBPXASB  LOOZC 

.BBS  PAOBCMS  0 

.DBCXABB  LZMBCMS  999  .BBM  OCAJMSBB  POH  BOZXABPXASB  LOOZC 

.DBCXABB  MAPPLAG  A1  .BBI  'X'  SDBMS  OH  BOZLBBPXASB  DZ8PXAX 
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8BT  MAVruUS  'X 


.RBC  *****  othar  Taxlabl*  dselaratloa  ***** 

.DKLAU  BLOCKS  B30  .KBI  MAMB  OT  BLOCK  TO  DOCOMKMT  (OB  BLL) 


.MM  *****  XABLB  DBrniTIOMS 

.BBM  ItalB  TablB  -  rom  Lav*! 

•DT  1  5  70  « 

.BBM  Main  Tabla  -  Block  Lorol 
for  2  10  70  • 

.MM  Mala  Tablo  >  Block  Latvol 
for  3  12  75  « 

.BBM  Main  Tablo  -  rlold  Lovol 
for  4  15  80  i 

.BBM  Main  Tablo  -  riold  Lovol 
«OT  5  17  90  « 

.BBM  Attrlbutoa  Tablo,  Form  Lovol 
•DT  6  17  32  33  44  45  CO  61  80  • 

.BBM  Attrlbutoa  Bom  Lovol 
•DT  7  14  14  15  80  • 

.BBI  rail  Moasago  Bozb  LotoI 

•DT  8  15  28  29  80  • 

.BBM  Trigger  Stop  Moasago  Tablo  Block  Lovol 
•DT  9  17  0  • 

.BBM  Trigger  Stop  Bttribotea  Tablo  Block  Level 
•DT  10  19  19  20  SO  • 

.BBM  rail  Message  Block  Level 
•DT  11  19  32  33  80  • 

.BBM  Trigger  Stop  Moasago  Field  Level 
•DT  12  19  0  • 

.BBM  Trigger  Stop  Mossage  Field  Level 

•DT  13  21  0  • 

.BBM  Trigger  Stop  Attributes  Table,  Field  level 
•DT  14  21  21  22  SO  • 


.BBM  Fail  Mossage  Field  level 

•DT  15  21  34  35  80  • 


.KBI  toMttn  Display  Tabls 
«OV  1€  1  to  « 

•or  17  17  32  33  to  f 


.DW  *****  SBUCT  SXiTBIIMT  OBrZXZYIOHS 

.MM  *****  Dsfias  tte  APffLXCiTZOM  1««^  aspost  Mlsct  asero 
.DBrm  JkPPSBL 

SlUtCt  AMID, 

APPTXTLI, 

fOjCmi(SX8DiXB) 

ZMTO  A»ID, 

APDTXTU, 

SOGAZ 

IVOM  8Z8SBI.XAPA» 

mam  oD»SR(Ap»cniBii)«apnit(c*naHHiio 

AMD  UPPER  (AraMAMB)«DPnil(CA»MAMB) 


.RIM  *****  DsZIimi  SBXMCT  aaexo  for  APPUCASIOM  lovol  nf  ntr 
.DEPIME  APPCMTSIL 
SBXJICT  CMSSBXS 
IMSO  CMITEET 
PROM  SZSSBI.IAPOOMfIMS 
MHEBB  CMEAPPXD  ■  AAPPZD 
AMD  OMTRIJC  Z8  MDU. 

AMD  CMSSWCTSP  Z8  MDUi 
ORDM  BZ 


.RBC  *****  DoflsM  tho  SBLBCS  aaozo  fox  BXOCR  l«v«l  ooMiBta 
.DBPZMl  BUGQCC8BL 
8BUCS  CMSSEXI 
IMTO  QgTEEI 
PROM  8Z8SBC.ZAPOOMIIMS 
MIIRB  CMSAPPZD  ■  &3PPZD 
AMD  GMSEUr  •  CBU90MB 
AMD  GMSPU)  ZB  MUXX 
AMD  CMtSRCSSP  ZB  MQZJi 
BT  CMELZMB 


.RIM  *****  Dafiaa  tha  BIZMCS  aaoso  for  PZIZD  larval 


ZMSO 

PROM 


aOAPPZD  ■>  AAPPZD 


AID  CMSSBflSSP  ZB  MDU. 
AMD  CMSZ.ZMB  >  1 
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ORDBR  mx  CMSTLIMB 


.KBC  *****  Dttflaa  tte  8IUCI  akczo  fox  rXBXC  larvol  boilozplmtM 
.Oirxw  rXJDgOZLSBL 
8EXMCT  GMnSZT 

onto  BOZLPZAn 

ISOM  mZBC.ZAPOOMIIIIT 

mm  acEftPPZo  -  cappzd 
AMD  aaaiK  ■  cBUonm 
AMD  OOriD  ■  fifXDMAm 
AMD  CMETMORP  Z8  MOLL 
AMD  GMZLim  >  1 
ORDIR  Mr  GMSLIMS 


.REM  *****  8SLMCT  aacro  for  APPLXCAXZOII  lovol  TRZGGKR  eoamnta 
.DBrXMB  APPlRIGCMfSKL 
8SLMCT  QtEIBCT 


IMTO 

CMTTEXT 

PROM 

SYSTEM.  lAPCOMIEMT 

RHEME 

OIEAPPID  ■  CAPPID 

AMD 

CMXBXJC  IS  MOLL 

AMD 

CMTTRSTYP  >  CTRIOTZPE 

AMD 

aOTRSSSQ  •  0 

AMD 

CMirLD  IS  MOLL 

ORDER 

BY  QITLIIIE 

.RBI  *****  8SLICT  aacro  for  BIDCK  laval  TRIOGMR  coaaanta 
.DBriMI  BUCTRIOCMTSSL 
8KLMCT  CNTTEXT 
IMTO  CMTTBXT 
PROM  8TSTBC.IAPOOMBMT 
mRRI  aOAPPZD  ■  CAPPID 
AMD  IB  CBUCMBB 

AMD  CMSrLD  IS  MOLL 
AMD  CMRRORP  >  CTRIOTZPK 
AMD  CNRRGSIQ  ■  0 
ORDER  BT  OITLim 


.REM  *****  SELECT  aaoro  for  PZEID  laaal  TRZOOBR 
.DETZME  TLDTRZ0CMI8EL 
SELECT  GMTTEXT 
IMTO  CMTTBXT 


MBERB  OflEAPPZD  >  CAPPID 


AMD  OgTRBTTP  ■  STRIOTTPE 
AMD  GMITRGSEQ  ■  0 
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.lOM  *****  Oanarie  SMfMCt  — cro  for  CTTOOP  STEP  eoaaoiito 
.DirziiB  RitsacrssL 
8MLMCX  CMCmn 
ZMTO  aSTBCS 
FilOM  SXSnM.IAPOOMIIIIT 
Wm>B  CMXBPPID  ■  CAPPID 
AMD  CMRMOTZP  ■  CTMIORPI 
AMD  CMRMGSIQ  ■  CTB08BQ 
AMD  CMSBXJC  ZS  MDLL 
AMD  001X0  Z8  MDU. 

ORDER  BT  OOLZME 


.REN  *****  Gonorle  SELECT  aocro  for  TRIGGER  STEP  eoMoato 
.DBPIME  BTROaOSEL 
SELECT  CMTTEXT 
ZMTO  CMTTEXT 
PROM  SYSTEM.  ZAPCOMIEMT 
MBERE  CMTAPPIO  >  AAPPID 

AMD  MVL(aaBLE,  ")  •  SBTEMAME 
AMD  CMTTRGTTP  ■  ATRZOTZPE 
AMD  CMTTRGSEQ  ■  STRGSEQ 
AMD  OOfXD  ZS  MOLL 
ORDER  BT  CMTLIME 


.REM  *****  Gonoric  SELECT  aacro  for  TRIGGER  STEP  coanHita 
.DEPZMB  TR0CNT8EL 


SELECT 

ZMTO 

PROM 

SYSTEM.  ZAPOGMIEMT 

MBERE 

OOAPPZD  ■  AAPPID 

AMD 

MVL(CMZBZJC,  "  )  •  ABLXMANB 

AMD 

MVL(CNZPZi),  ")  ■  APU3IIAME 

AMD 

AMD 

CMTTRGSEQ  ■  ATRG8EQ 

ORDER  1 

nr  CMTLIME 

.REM  *****  Daflaa  tha  SELECT  aaero  for  APPLZCATZON  lanral  trig 
.inriMB  APPTRZG8EL 

SELECT  MVL(TRIGBLX,  "  )  , 

MVLCTRZGPZi),  "  ) , 

TRZOTZPE, 

MVL(TRZGDESC,  'NOME' ) , 

OBCOOE(TRZGBIDE,'T',  'YES', 'MO') 

ZMTO  BZEMANB, 
rXEMAMB, 


TRZOTZPE 


ntiGDBSC, 

TRIGBIDB 

FKOM  SXSnM.ZAPmOGn 
1IHB»  TRIGlkPPXD  «  ftAPPID 
JUn>  TRIGBLK  Z8  MOLL 
ORDBR  nr  TRIORPB 


mi  *****  DafixM  th«  SBUCT  Mcro  for  BLOCK  latvol  trlggora 
DBrm  BLKIRIG8BL 

8BLBCT  IIVL(TltZGrU>,  "  )  , 

TBZORPB, 

MVL<TltIGDB8C,  'MQMB' ) , 

DBCOOBCSRIGBIDB,  'T' ,  'BBS' ,  'MO' ) 

IMTO  rUMOkMB, 

ntzontPB, 

TRIGDBSC, 

TRIGBIDB 

ntOM  STSTBM.ZBPTRZOGBR 
BBBBB  ntIGBPPZD  -  CBPPID 
BMD  TBIGBLK  «  CBUOIMIB 
AMD  TRIGPLD  Z8  MOLL 
ORDBR  BT  TBIGTYPB 


mi  *****  Dofiao  tbo  8BUeCT  mero  for  PZBLD  lorvol  trigger* 
xnrDiB  rxzmuGBBL 
8BLBCT  TKIOrrPB, 

1IVL(TBIGDB8C,  'MOMB' ) , 

OBOODB(TRZGHZDB,  'T' ,  'TB8'  ,  'NO'  ) 

IMTO  TRZGTZPB, 

TRIGDB8C, 

TRZGBZDB 

PBON  BYBTBM.IBPTKZOGBR 
MBBBB  TRIGBPPID  •  UPPZD 
AMD  XRZGBLK  >  tBUCHMg 
AMD  TRIGPU)  ■  cnOMBIIB 
OBDBR  Bt  TRZOTZPB 


me  *****  Doflao  tha  gaiMrie  BBZBCT  aoero  for  triggar  atapa 
DBPIMB  8TBP8BL 

8BLBCT  TRB8BQ, 

mCLBBBL, 

TRGBQL, 

DBOOOB  (TBOCOR8,'T', 

DBCOOB(TB0ZHP,  'T'  ,'*',") , 

DBCOOB  (TBaMPB,'T', 

DBOOOB <TBflBOLL,  'X'  , 

TR08LBB, 

SBoruui, 

XKCBttG 
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uro  ti«b8iq, 

TROIAKL, 

SQXIIO, 

TKOCOnS, 

XRGIIIV, 

TBOMVB, 

TSGBOUi, 


noM  sxsTBi.iJkpsns 

laBRI  ZSGaPVID  «  UiPPID 

JOB)  moncps  -  ctrigrpx 

AMD  MVL(T»CBLK,  ")a«BXJQIBMB 
AMD  TROnO  IS  MDLL 
QKDBR  Mr  ntGSXQ 


KBC  *****  D«fin«  tb«  T(MIM  saport  salaet  aaero 

DKrzMB  rsnpsxL 

SSLMCT  TRBSKQ, 

TR6LABBL, 

VnSSQL, 

DSOODKTRaCDRS,  'T'  « 

DKOOOB  (TRBIMV,  'T'  , 

DBOODB(TMafVB,  'T'  # 

DMOODB(XnSROLXi,  'T'  » 

TRSSLAB, 


XMTO  TRSSBQ, 

TKGLABKL, 

SQXIK), 

TR0CUM8, 

TR6IMV, 

swaivE, 

TRGMOLL, 

tnSSLAB, 

TRSTLAB, 

VROMSG 

MROM  STSTBC.IWTRO 
mBRB  TRSAFPID  •  UPPZO 
AMD  TROTXPB  <■  CTXXOTXPB 
AMD  ntOBUC  X8  MDLL 
AMD  TROriD  X8  MDLL 
ORDER  MX  TR08BQ 


KBC  *****  DaflM  tha  rXBLD  laral  rapoxt  triggar  aalaet 
IMD'XMB  ni)8TBP8XL 
8BLBCV  TR08BQ, 

TRSLAMEL, 


TRGSQIi, 

raoooKTiiacaRS,  't'  , 

OBOQOI  (TRSniV,  'T'  » 

DBOCX>B(TiaaiVK,  'X'  / 

DBOODB(TItGROLL,  'X'  « 

TKGSXAB, 

TnsrxjuB, 
xiuaisG 
ZMTO  xncssQ, 

TBCIAML, 

somo, 

TROCORS, 

TRCniV, 

TRGMVI, 

XRGRDU., 

TRCSIAB, 

TROXRB, 

TRGKSG 

XROM  SXSXBf.IAPTRG 
1IBIRS  TRGRPPZD  ■  CRPPID 
AMD  TROmS  >  CTRZGIXPR 
AMD  MVL(TR6BLK,  ")>CBLXK»MI 
AMD  MVL(TRGrU>,  ")«CrLI»IAia 
ORDER  BX  TRGSRQ 


.RRM  *****  D«£ln«  tbm  9«n«rlc  SRXiMCX  mcco  for  trlggor  tart 
.DiriMS  XRGIXTSXX. 

8IUCT  SQTTKXT 
IMTO  80TXBCT 
FROM  8X8TSM.  IAPSQZ.XXT 
MBXRB  8QSAPPID  >  AAPPID 
AMD  somo  -  C8QTMO 
ORDER  BX  SQTLIME 


•  REM  *****  DoflxM  tha  BX^OCK  laral  xaport  aalact  Baero  (ALL  BXOCKS) 
.DETIME  BUC8EL 

SELECT  BLXMAME, 

MVL  (BUCDESC, '  ROME' )  , 

BLK8EQ, 

DECODE (BLEDMQREX,  'X' ,  'XE8' ,  'WO'  )  , 

DECODE  (BLKXMAME,  MOLL, 'CONTROL  BLOCK', 

DECODE  (BLKTONMER, MOLL,  MOLL,  BLEXONMERI  I '.' ) 


BLEMOBOr, 

BLKBLXM, 

BLXLMRC, 

MVL(B1IC0BX8QL,  0} 
IMTO  BLEMAME, 

BLKDESC, 
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BXJOliiaOT, 


blxblui. 


UUSUOtC, 

SQTNO 

non  R8TBI.ZAPBXJC 
mKRB  KJOUPPIO  ■  CAPPID 
ORDBR  BT  BLK8KQ 


KIM  *****  Daflaa  th*  WXJOCK  l«v*l  saport  aalaet  —ero  (0MB  BZdOCK) 
dbpub  ombilksbti 

BZJQIKMB, 

MVL  (BLKDB8C, '  MOHB'  )  , 

ILKSBQ, 

DBOOOBCBLXmiQKBr,  'T' ,  'TB8' ,  'MO'  )  , 
DBOOOB(BXJCnaMB,MDLL, 'OOHTROL  BLOCK', 

DBOODK(BIJCTOIIIIKK,MDLL,MOLL,ILKTOIPIBR|  r  . '  ) 

I  IBLKnOMB) , 

BLKMOKBC, 

BXJCMOraP, 

BLKBLZM, 

BLXLMRC, 

MVL(BZJEOBKS<2L,0) 

XMTO  BuaaMB, 

BXJ0DB8C, 

BIKBMQ, 

BLRUMQRBT, 

BUCSMKNB, 

BLKMOKBC, 

BLXMOBOr, 

BMBLIM, 

BUCLHKC, 

SOTNO 

PROM  8T8TBN.ZKPBUC 
MHBRB  BLKKPPID  ■  CAPPID 

AMD  DPPBR(BZJaiAMB)  ■  OPPBR(CBLOCK8) 


PBI  *****  Dsfiaa  tlM  riBXD  !«*•!  report  saloet  aaero  ***** 
DBPXMB  PLDPBL 

8BLBCT  PLDMAMB, 

IXD8BQ, 

fXDRPB, 

PLDLBN, 

riDQLBN, 

DBOCOBdXDBCAB,  'T' ,  'TB8' ,  'MO' ) , 

DBOODBdXDKBT,  'X' ,  'TB8' ,  'MO' ) , 

DBOOOB(rXi)CKBLK,IR7LL,MDLL,rU)CKBLK|  I'  .')  I  irLDCKFU), 


8S 


rLDDrz.T, 

DBOOI»(nDDI8P,  'T' ,  'TBS' ,  'MO' )  , 

i»ooDK(ru>ximR,  't'  ,  'tbs'  ,  'mo'  } , 

DBCCX>B(nDQDBiar,  'X' ,  'XB8' ,  'MO'  )  , 
DBOQOB(ni>DPDBXB,  'T' ,  'XB8'  ,  'MO'  )  , 
DBOODBCnDOTOMDL,  'X' ,  'XB8' ,  'MO'  )  , 

DBOODBCrLDMBMD,  'X' ,  'XB8'  ,'MO'), 

OBOOOB(rXi>riXBD,  'X'  ,  'XBS'  ,  'MO'  )  , 

DBOOOB(rU>8XIP,  'X' ,  'XB8'  ,  'MO'  }  , 
l>BOQOB(nDHIDB,  'X' ,  'XB8' .  'MO'  )  , 
OBOOOBCrLDKITOBLP,  'X' ,  'XBS' ,  'MO' )  , 
DBOOOB(rU>OPPBR,  'X' ,  'XB8' ,  'MO' ) , 
DBOOOB(ni>LOVT,MaLL,MnLL,rUDX/3VT|  I'  .')  I  IPXALOVC, 
nOLOM, 

PLDHI, 

FICHBIP, 

PLDPJUa, 

nOLIMB 

XMTO  rUINMIB, 

PLDSBQ, 

rZDTXPB, 

PLDLBN, 

nDQLBM, 

flSBCBB, 

IXDXBX, 

PIDCKIXD, 

wwonv, 

IXDDISP, 

PLDBNTBR, 

IXDQOBRX, 

riDOPOBTB, 

riDUPDNUL, 

rUMOkMD, 

PIDPIZBD, 

riDSKIP, 

rXSBIOB, 

nOBOTOHXf, 

riDOPPBR, 

IXDLOVC, 

rXDLOM, 

rXDBI, 

IXDHBlff, 

riDPAOB, 

flCLIMB 

PROM  SXSTBN.ZBPPLD 

MBBRB  riDBPPZD  ■  &BPPXD 
BHD  PUBLK  B  BBLIONBIB 

ORDBR  BX  rZOSBQ 


mi  *****  SBXiBCT  aacro  for  PIBU)  1«t«1  doaerip 
DBPXMB  riDDBSCSBL 
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•uacr  TLPPIICTIPT 
XmO  FXCDB8CRZPT 


IKON  niID_pB8C 

miiiB  cmo**  uruMMU 


.RBt  *****  SKTJtCT  Mcro  for  ■LOCK  lovol  total*  d**erlp 
tiMTMM  ■ZJCXDKSCSSL 
SBZaCT  TDBSatlPT 
ZMTO  SDB8CRZPT 
VnOM  1!IBIB_1»8C 
mu  Tnu~a  CBXJEnOMI 


.UN  *****  Dafia*  tta*  8KUCT  aaero  for  BoUarPlat* 


ZMTO  lOPPJUS, 

MtaPLIU, 

uPTsn 

UOM  STSTKN.IUIOP 
MUn  lOPAPPID  ■  UPPZD 
ORDU  BT  iaPPAfiB,iaPLIU 


.UM  *****  Dofla*  Mloct  aaero  to  got  loggod  on 
.UM  *****  ua*r  naa*  (^poimar) 


.DETIU  GBTOSn 
8SUECT  usn 
ZMTO  taPPOMMU 
PMOM  STSTDC.ZtaPtaPP 


.UM  *****  8TUT  UT 

.UN  *****  Dofin*  tta*  MPPLZCtaTZOM  l*v*l  raport  bod^ 
.UN  *****  PRZMT  HUDU,  DtaTM,  TZTIB,  ONMU 
.UM  *****  RDM  PORN,  BLOCK,  PZBU)  IBVBL  ZMTO 


.DBPZn  BPPBOOX 
tT  I 

is  2 
•8  1 

DOOOMBMTBTZON  lOR  80L*rCRm  BPPLZCBTZOM:  \  \ 
.PRZMT  BPPM8U 
18  1 


.PRUT  TODRX 

«NC 

TITXJE: 

.PRUT  APPTITXX 
iNC 

omiRR: 

.PRUT  APPOmiRR 

«8  2 

fCRH  PORM  ZJEVKL 

•M 

********** A*^***********************i 

iN 

.RXPORT  RPPCMTSXL  OOBOOT  CMTBBRD 
.TC 

.REPORT  RPPTRI68BL  RPPTRZGBQOT  RPPTRIGBSRD 
«T  1 
«8  2 

************************************^ 
iCU  BLOCK  LEVEL 

iM 

************************************^ 

«TE 

.IP  "iBLOCK8  IS  MOLL"  TBU  RLTJIL0CK8 
.REPORT  OMEBLKSEL  BLXBOOT 
.GOTO  EMDBLOCRS 
.CALLBLOCK8 

.REPORT  BLKSEL  BLKBODT 
.CENDBLOCKS 

.IP  "CMEPPLEG  !«  'T'"  THU  END 
«T  16 

«8  4 

.REPOTX  NRPSEL  NEPBODY 
«TE 
.CEND 


.RU  *****  PRUT  OOMIENT  HEEDU 
.DEPUE  CMEHEED 


#8  1 


.RU  *****  PRINT  OOMIENT  TEXT 
.DEPUE  CMTBODY 
.PRUT  CMTTEXT 


.RU  *****  POU  LEVEL  TRIOGU  EERDU 
.DUUE  RPPTRZGBE8D 
«T  2 
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«8  2 


. ntXOGBRS 

•8  1 

•TB 

.AFPfltZGBOOT 


.BBC  *****  rone  UVBL  niXQGBR  BOOT 


iT  2 

TXTB: 

.BBIBT  naORTB 

•» 

OB8GRZmOH: 
.BBIMT  VBXGDB8C 

•M 

BIDB: 

.PBXMT  TBZ6BIDB 

fB 

•n 

•8  1 

.BBTORS  r8TEP8EL  8TBrBaOT 


.BIM  *****  rone  UEVBX.  TBXOGBB  XBronosiCM 
.DBrun  BnrBooT 
IT  3 

8TEP  • 

.PBZMT  TBG8BQ 

«w 

L8BBL: 

.PBIMT  TB6LBBBL 
«TB 
*T  4 
#8  1 

.BBPOBS  TBCXXT8BL  TBOTXTBOOT 
.BBPOBS  rXBOCMT8BL  CMSBOOt  CMTIIBBD 
#8  1 
«TI 
it  7 

.PBXMT  TBOMRB 

fNC 

ABORT  TBXOGBB  BBBM  8TBP  PBXXB 

iNC 

.PBXMT  TBGXMT 

•MC 

BBVBB8B  BBTUBM  OODB 

INC 

.PBXMT  TBOBOU. 

«NC 
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RBTDMf  SOOCISS  OH  ABOHX 

•MC 

.PHZMT  TROCDRB 

§ac 

uaxuam  corsor  drxr  arbr 

iMC 

iNC 

*8  1 

800CS88  ZABIL: 

.nOMT  TR6SZAB 

iMC 

iMC 

naunti  zabbl: 

.PRINT  TRBPZAB 

fTB 

.IPMDU  TRGMS6  MO  I!RXXi_M86 
iT  8 

PRIL  M8888GR; 

•MC 

.PRINT  TMM86 
«TB 

.SMO  IRIL  M8G 
•T  4 
#8  1 

.REPORT  RPPTRIOCMISBL  CMIBOOT  OITBBRO 
#TE 
#8  2 


.REM  *****  PRIMT  TRIGGER  8QX.  8TRTENEIIT 
.DEPIME  TROTXTBODT 

•rr 

.PRINT  8QTTEET 


.REM  *****  BI^OCE  UVEL  IMPORNETIOM 
.DEPIME  BLEBOOT 
iT  2 
•8  2 


iM 

\  \  Block 

.PRINT  BXX8EQ 

• 

.PRINT  BLEMRME 
iN 


•8  1 

iTE 
iT  4 
iN 

BLOCE  DB8CRIPTI0M: 
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.pkur  bucdisc 

•» 

CPBU  Bam: 

.prur  BucfmuMB 

§M 

.MPORT  BLXXDB8C8KL  BLKZDBSGBOOr  BXJCZSSSCBUkD 

•» 


m 

in 

#T  4 


iNC 

Moen  or  nous  Dispuno: 

.PRUR  BUaiORlC 

#NC 

MDMBIR  or  ROWS  TO  BDFPRR: 
.PRUR  BXJCMOBOr 

flic 

.IP  "CBUOIORRC  >  1"  THEM  LRBRLl 
MOMBRR  or  LZMR8/R0M8: 
.PRUR  BUOMRC 

•mc 

■R8B  LIMB: 

.PRUR  BUCBI.IW 
.CZABXLl 

in 

.IP  "C8QTIIO  -  0"  THRU  MO  ORDBR  BT 
#T  4 
•8  2 

. DEPBULT  ORDER  BT 


#M 

.REPORT  XROXXT8EL  TROXXTBOOX 

in 

.  C1I0_0RDER_BT 

.REP^  BzjcZRIG8EL  BURRIGBODT  BXJEIRZ6BEBD 
*T  3 
#8  1 


iN 

\  \  \  \  \  PIEXM 

iM 

#8  1 

in 

.REPORT  PU>8EL  PXCBOOT 
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SABLI  DBSCKCBTZOil: 
.BXJCZDBSCBOOr 


.BBI  ***** 

.DirZlIB  BXJCSDBSCBCOr 
.PRUIT  BXB8CRZPT 


.WDi  *****  BLOCK  ZBVBL  TKZOGBR  BBBSBR 
.IWZIB  BUCnaCBBLD 
iT  4 

is  2 

.  XRZOGBRS  . 

•8  1 

«TB 

.BLKTKZGBOOy 


.BBM  *****  BLOCK  LBVBL  TItZOGKR  BOOT 
.DSTIMB  BLXTRZGBOOV 

iT  4 

at 

TXPM: 

.BRZMT  TKXOrZPB 

in 

OB8CRZPTIOM: 

.PKIMT  TBZGDB8C 

in 

BIDS: 

.PRZMT  TRIGBIDB 

in 

.BKPORT  BLKTRI0CNT8BL  OITBOOT  CMTHK8D 

is  1 

«TB 

.KBPORT  8TBP8BL  BSTBPBOOT 


.BBM  *****  BLOCK  JMVKL  TBIOGBR  mPOnaTZON 
.OBPZIIB  BSTBPBOOT 
#T  9 

•M 

STBP  - 

.PKHIT  TBG8BQ 


.prur  tmslbbsl 


•n 

#T  12 

«8  1 

.WEfOta  nOZXTSKL  nXWXTBOPT 

.KBPonr  smocMTSSL  caoBOor  cmxbud 

*8  1 

«n 

«T  10 

.PRINT  TRGMPB 

me 

ABORT  TRXOGBR  mBH  8TBP  PAILB 

me 

.PRINT  TBSINP 

iNe 

RBVBR8B  RETURN  CODE 

*NC 

.PRINT  TRfiROIJ. 

«Ne 

RETURN  8UeeE88  ON  AB(»T 

«Ne 

.PRINT  TROCURS 

•Ne 

8EPARATB  CDR80R  DATA  AREA 

me 

iNe 

#8  1 

8UeCE88  XABEX.: 

.PRINT  TR68LAB 

iNe 

iNC 

PAIUURE  LABEL: 

.PRINT  TRGPLAB 

me 

iTE 

.IPNOLL  TRai8G  N0_IAIL_1I86 
iT  ii” 

PAIL  NE88AGE; 

iNe 

.PRINT  TRai8G 

iTE 

.CNO  PAIL  N86 
i8  2 


.REM  *****  riELD  LEVEL  narORAMTIGN 
.OEPiNE  rxDBcmr 
iT  4 
i8  2 

#*#*********************^ 

m 

\  \  riEU) 

.PRINT  PLDBEQ 


93 


«ll 

«n 

ix  5 

.UPORX  IXODBSCSKL  WUXOmaCBODI  WmomaCBMMD 

•n 

#*  4 

«n 

«T  17 

.maaan  ixoboilsxl 

IM 

.XT  "CnDPAfil  ■  0"  THBf  PAG1_UI(0 
BOIUBRPXATS: 

*1IC 

.PRINT  BOILPUITI 

•NC 

. «PAGR_SlRO 

~  ZASRTXPK: 

•MC 

.PRINT  IXDRPR 
#NC 

riRLD  UNOTH: 

«NC 

.PRINT  ru>zm 
«MC 

QOXiar  UNOTH: 

INC 

.PRINT  riDQXXN 
iNC 

PRGS: 

«NC 

.PRINT  PIDPRGB 

«liC 

LINE: 

«NC 

.PRINT  rUDLINB 
«NC 

.IPNDLL  WIDCXriD  NOjnDjCK 
OOPX  EBT  PROM: 

«1IC 

.PRINT  PIDOCnD 

«NC 

.anjrxcMCK 

.IIN^  rUJDPLT  NOjrLDJ)rLT 
DEPADia  vii^: 

iNC 

.PRINT  PIDDPLT 

•NC 

.CNOJTLDjnXT 

.iwmLL  wuium  no  renqb 
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IttllGl  LOW: 

Inc 

.PRZMT  WUXXJCm 

iwc 

BXGH: 

«MC 

.ntZMT  rXAHI 
«1IC 

.innui  FicLovc  No^raojiovc 
LZSTjnoTuiix: 
fae 

.VRXirr  rxcLovc 
.«1ID  no  LOVC 

“  #lic 

.XniDUl  IXDHBLP  liq_lli)JBELP 

#TE 

iT  5 

BBXf : 

.PRINT  riDBELP 
«TI 
#T  17 
.  CNq_riD_BRX« 

”  #T* 

•T  5 

.REPORT  rXJXXSSML  CMTBOOT  GMCHERD 
#8  1 

-  ETTRXBOTBS  * 

«8  1 
#TB 
•T  6 

DRTRBR8E  PIEU): 

•NC 

PRINT  PLDBTRB 

INC 

PRIMERZ  RET: 

me 

.PRINT  PIDKET 
«MC 

DI8PZAXED: 

fMC 

.PRINT  IXDOI8P 

me 

.IP  crU)DI8P*'IIO'  THEN  END 
QUERX  RLDOlIRD: 

me 

.PRINT  PIDODERT 

me 

INPUT  ELDOMED: 

me 

.PRINT  IXDENTER 

me 
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.ir  ftrxDBiTES^'iio'  noM  bmd 

UPIAn  JOAONID: 

•MC 

.VRZMT  ruraPSHTB 

iMC 

OPD^TB  ir  MOLL: 

«NC 

.PRiMT  nDDPDmn. 
iMC 

FIXED  UNOIB: 

#NC 

.PRXMT  rXDFIXBD 

•MC 

MEMDETORT: 

•MC 

.FRUIT  FXJDMMin 

#MC 

RDTOSKXF: 

•MC 

.PRINT  FLDSKIP 
#MC 

MO  ECHO: 

#MC 

.PRINT  noaioE 

#MC 

ROTO  HELP: 

•MC 

.PRINT  WUamOBXJf 
•MC 

UPPER  CASE: 

•NC 

.PRINT  nOUPPER 
•MC 

.SEND 

#TE 

.REPORT  nOTRIGSEL  FIDTRIGBOOT  FLDTRIGBERD 


.REM  ***** 

.DEFINE  FLDDESCBERD 
iRR 

DESCRIPTION: 

.FUOESCBOOY 


.REM  ***** 

.DEFINE  FLDOESCBGCnr 
.PRINT  FLDDE8CRIPT 


.REM  *****  FIELD  TRIGGER  BERDER 
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.DBriiB  ruyaaoBMMD 

it  4 

•8  2 

\  \ . TRIOGnS 

•8  1 

•TB 

.lli>TRIGBOOr 


.RBC  *****  riBXi)  LKVKL  TRIOGBR  BOOT 
.OBTIMB  riDTRIGBODT 
•S  5 

iv 

TZPB: 

.PRINT  TRZOTZPI 

IN 

OX8CRIPTIOM: 

.PRINT  TRXGORSC 

«N 

RIDS: 

.PRINT  TRIGBIDR 

«N 

.RXPCNKT  IXDTRIGafT8IL  CMTBOOT  CMIHRRD 

«8  1 

iTR 

.REPORT  rLD8TRP8BL  PIDSTEPBODT 


.RXM  *****  riKID  LNVBX.  TRIOGBR  INPCXniRTION 
.DBPINB  rU>8TBPBOOT 
«T  12 

IN 

8TBP  • 

.PRINT  TRG8BQ 
«N 


.PRINT  TR6LRBBL 
#TB 
#T  13 
«8  1 

.RBPORT  TBGTXT8XZ.  TBOTXTBOOX 
.REPORT  TROOITBXX.  GNTBOOX  CMTBB8D 
«8  1 

«TB 
#T  14 

.PRINT  TRGNPB 

«NC 

ABORT  TRIOGBR  NBBN  8TBP  PA1X.8 

•NC 

.PRINT  TRGINV 

•NC 
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RIVIRSB  KITOm  OOOB 


tMC 

.PKIMT  TSCROLL 
«NC 

RBTDmi  SDOCSSS  OM  t^MOKS 

•NC 

.VRIMC  TBOCDKS 
«MC 

SBPAMITI  C0R80R  DUZH  AUH 

flic 
INC 
«8  1 

8II0CB88  ZABBL: 

.PRINT  TR68L8B 
iMC 
INC 

PAIUIRI  XABRL: 

.PRINT  TROrZAB 
«NC 

#TI 

.IPNOLL  TRGMS6  N0_TRIL_1ISG 
iT  15 

PAIL  1IB8SAGI: 

flic 

.PRINT  TRGM86 

iTK 

.CNO  TAIL  M8G 

“  #8  2 


.RBI  *****  ORAN  THE  8CRSRN 
.ORTINB  NAPBODT 

.IT  "CPAGBCNT>CNAPPAGR"  THEN  LABELl 

•8  1 

PAGE 
•  MAPPAGE 
iNC 

.EOOAL  PAGBCNT  NAPPAGE 

«8  1 

.8ET  TiTNECNT  1 
.CLABBLl 

.IT  "CUNECNT-AMAPLINE"  THE  LABEL2 
.IT  "8LINECNT»l»«NAPTiTNE"  THEN  TABELH 
#8  1 

.CLABEL3 

.ADO  IiTNECNT  LINECNT  1 
.GOTO  LABELl 
.CLABSL2 
iCL 
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.VRIMT  lOPTEn 

flic 


.mi  *****  z«glc  to  idantlfy  tho  applleation,  atart  roport  *** 

.GOTO  GBTJDSIR 

.CBAD_APPn> 

.TEUr-COOUHIt’ T  rZK)  APPLZCATZOM,  XlOr  MOklM  OR  CTRli'T  TO  GPIT" 

.CGBTJDSIR 

.mCUTB  6K08IR 

.ASK  "MMIK  or  THB  8QL*rORII8  APPLICATION:  **  APPMUIB 
.SKICUTK  APP8KL 

.ir  "4APPZD  IS  MOLL"  TBBI  BSD_APPID 
.ASX  "DISPLSX  SCSmi  MSP?  (T)  "  MSPIXAS 
.SXT  BTJniSMl  »  " 

.SIT  rLDNSMB  **  ** 

.PACK  0  60 

.RXPORT  APPSXL  APPBOOY 
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Appendix  H.  Data  CoBectkw  PTfigr— 


—  ♦  *  j  » »  »IM  M  M  M  H  t  M  H  I  «  *  M  H  I  I  1  -f 

—  FACILITr: 

—  Air  roxca  Instltuta  of  Toehnology,  Wrifpkt-Pattoraon  AIB  OB 

—  ABSTRACT: 

—  IT2  providoa  aoftwaxa  support  aaaattraaont  for  Oraclo 
databaso  applicatlona,  by  prompting  tba  analyst  for 
additions,  ehangas,  and  dalations  to  tba  basalina. 

—  It  also  proridss  siring  by  analogy  by  scanning  tba  basalina 
of  8QL*roms  data  dictionary  reports  idantifiad  by  tba 

<—  analyst  as  sijailar  to  tba  softwara  siqpport  raquastad. 

—  ADTBMl: 

Capt  Stauan  D.  Radnor,  ATIT/LSG  GS892D 

—  CRKATIOM  DATI: 

Dae  92 

—  MQOZFICATIOM  BISTORT: 

{tbs> 


pragma  paga; 
with  Taxt^ZO; 

witb  Xd.st^DoublaJCbiboundad_Managad;  — -  Booeb  Coaponant 
proeadura  rP2  is  pragma  Optimisa  (Tism) ; 
typa  Data^typa  is  digits  3; 

package  lfatural_lO  is  naw  Tazt_IO. Iatagar_IO (natural) ; 
package  rioatPt_lO  is  naw  Taxt_IO.rioat_IO(Data_typa) ; 

—  Actions  naoasssry  to  support  8BR  to  anhanna  databasa  applications 

typa  8N_S<9port_typa  is  s/w  si^port  function  point  actions 

(ADDBD,  —  naw  functionality 

CBAIRSB),  "  modification  of  asisting  functionality 

DBLBTID,  —  delation  of  existing  functionality 

TOTAL);  —  total  of  all  software  support  function  points 


typa  8irjraaction_typa  is  —  Oracle  databasa  application 
(TRAMSACTI0II8,  —  forms,  r^rts 

Z1IPUT8,  —  trigger  steps,  select  statsmsnts 
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BNTZrZSS 


— ‘  blocks,  tables 


OOTFOTS); 


— •  fields,  print  statasMBts 


— '  ttaadjusted  ruaetion  Foiats  aetslx 
type  tnrFjbype  is 

esssy<Sir__8i9postjtype,8lf_FnBetioa_type)  of  aetursl; 
psegaa  page; 

Faehaieal  Coaplaotity  kdjuataant  scale 
subtype  TCk_8eale_type  is  aatusal  range  0..5; 


Faehnical  Co^plsocity  kdjnataaat 
—  characteristics  for  array  of  scale  valnes 

type  TCkjCharacteristics  is  ( 
DatajOaaeuaication, 

Distribated_Fuaction, 

Ferfoxaance, 

■eavilyJDsedjConfiguration, 
TraasactioaJRates , 

OnLi  neJPata^Knt  ry , 
OesignJTorJbidJDserJBfficioncy, 

Onl  inejtqpdate, 

Ce^lssityJProcessiag , 
Usable^ZajOttaer_l^licatioos , 
Zastallatioa^Base, 

Operations Jase , 

MoltiplejBites , 
racilitatejChange, 

Requiraaent  s jOf jOther_J^plioatioas , 
8ecttrity;_FriTae7_kuditability, 
User_yrain4nq_llaeds , 
Direet_nse_By_ThirdJParties , 

Docuaant at ion , 

Client  Defined  Characteristics); 


—  mxxmf  of  characteristic  Talaes 

type  TChjtype  is  array  (TChjCharacteristies}  of  fChjscalejbype; 
pra^  piqm: 

—  loop  and  string  slice  constants 


SBR_ltai_Zaagth 

:  constant  positiTe 

5 

Masjsnsjbength 

:  constant  positive 

:>  40 

llas_FileJMae_Zangth 

:  constant  positive 

C5 

Mas  Line 

:  constant  positive 

80 
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—  string  aubtypns 


•iibtypn  8Slt__lluabnr_typn  is  string  (1.  .SSR^Mui^Lsngth) ; 
subtyps  Wsnsjbyps  is  string  (1.  .llsx_Maas_Langth)  ; 

sttbtyps  rils_llaasjbpps  is  string  (1.  .llsxjrils_Kaas_Lsngth) ; 
subtyps  Xdnsjtyps  is  string  (1.  .Max_Lins_Lsagth) ; 

fV2_Bslp_rilsnaaM  :  rils_Jlaas_typs  :«  (otbsrsii>'  '}; 
JbqfjChsr  :  ehsrsctsr; 


—  Input  function  points 

type  St^_llods_typs  is 
mcord 

Haas  :  MssuMbyps  :>  (othsrs  ■>  '  '); 

Support  :  SII__8i:pportJKyps  SOCSL; 

•nd  rscord; 

psekags  Stsp_Zd.st  is  now 

List_DoubloJDiBboundod_lisnsgo<1  (Stopjodojbypo) ; 


— >  Output  function  points 

typo  riold_llodojtypo  is 
rocord 

Waiss  :  MssMjtypo  :<■  (otbors  ■>  '  ' ) ; 

Support  :  SWjBvpportJQnpo  :■>  TOESL; 

Stops  :  StopJU.st.XJL.st  :«  StopjUst.MuUjUst; 
ond  rocord; 

pseksgo  Fiold_X>ist  is  now 

liistJoublojObboundodJiBnsgod  (rioldjcdojbypo) ; 


—  Procoss  function  points 

typo  Block_lfodo__typo  is 
rocord 

WsM  :  HasMjtypo  :■  (otbors  >>  '  '}; 

Support  :  SII_SY9portJ^fpo  :■  TOXkXi; 

Stops  :  Stop^Ust.Iiist  :■  Stsp^Id.st.ltall_lJ.st; 
Piolds  :  riold_Ust.Ust  risIdList.lbJi_Ust; 
ond  rocord; 

psekags  BlockJUst  is  now 

ZtistJDoubloJDlabouadod_llanagod(Block_Hedojbypo) ; 


—  Transaction  typos 

typo  J^_llddojtypo  is 
rocord 

ItasM  :  PiXoJIaMajbypo  (others  ■>  '  '); 
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on  :  :•  (otlMxs  ■>  (0,  0,  0,  0)  ); 

Support  :  SITjSvpportJVypo  :■  SOEAL; 

Stopa  :  8tap_Jd.at.Xilst  :■  8t^_l«iat.Mull_U.at; 
■looks  :  Blodk_List.Xdst  :>  Bloek_List.»iIi_Liot; 
•nd  aooord; 

pscfcsgs  App^ldst  is  BOW 

List JoubloJOtoboundodJiansgort  <App_Modojbypo) ; 


—  SIR  iafozBStion 


typo  Fxojoet^llbdojtypo 
soooad 


is 


SUM  ZD 


Sost_1lks 

Cods__Bss 

SostJBss 

DFSs 

SCk 


■_typo 
Dstsjtypo 
Datsjtypo 
Ootsjtypo 
Ostsjtypo 
:  DfS_typo  :■ 

:  TCkjtypo  ;■ 

8pp__Llst .  Zdst 

rsooxd; 

pseksgo  Psojoet_Zd.st  is 

Ii.st_poubloJOaboundod_llsnspo<l  (Pro  joet_llodojtypo) 


(othors  ■> 
(othors  ■> 

0.0; 

0.0; 

0.0; 

0.0; 

(othors  ■>  (0,  0,  0,  0)  ); 
(othors  ■>  1); 

:■  hpp_List.>nll_list; 


Projoet  :  Projoet^Ziist.Ziist; 

ProjoetjOption  :  eharsetor; 

—  ♦«-»■»  t  M  ♦  ♦  *********+*****¥*■*******  ♦♦♦mum  n  H  t  M  n  n  M  i-n 

—  Proopt  usor  for  projoet  8ER  f 


prooodoro  OrntJUR  (SBR^Vua:  out  SU_M«aBborjtypo)  is 

Buff  or  :  Zdaojbypo; 

8trii>q_Ziongth  :  intogor; 

bogin 

sn.llHB  :■  (othors  «>  '  '); 

Soxt_IO .  ■ow_Ziiao; 

Soxt3EO.PutT"Bator  tho  Softwsao  Bagiaooriag  Roquost  mabor  :  **); 
SOrt_^ZO.Got_Liao(Buffor,  8triiig[_LaDgth) ; 

if  8triiig[_ZiOBgth  >  8BR_llao_Zongth 

thoa 

Swt_ZO.  Msw^Liao; 

SOBt~’zo.PutT"n»  Mum  truBCStod  to  — S 


1(» 


.8EIlJta»l«Dgth)  c 

SBRJItad . .  SERJfimJbwtgth)  :•  Boff ax  (1 . .  SBRMumJCMgtb)  ; 

Vaxt_IO .  Mair^ZdJM ; 

•iM 

8BR_m»f  1 . . String  Luothl  :■  Bo£C«x(l.  .Striagjbangth)  ; 
and  If; 

•nd  Gat_8ER; 

—  ♦♦♦♦♦  ♦  M  M  H  »»-«-» »*-»4  4"f  ♦  M  » I  M  I  i  I  M  M  H  ♦  >  I  H  H  H  t  M4  I 

Fxoaipt  ttsax  for  tho  toaa  . . . 


prooodaro  Gotjfoaa  (Voaa^ZD:  out  W— jtypo)  ia 

Buffar  :  XdjMjtypa; 

Strin^jLangth  :  intagar; 

bagla 

Vast_ZO.Put 

("Batar  aach  aHibar  of  taaa  alphabatieally  (uaiag  a-aail  ZDa) ,  ") ; 
Tazt_ZO .  llaw_Zdna ; 

Tast^IO.Fut {"aaiparatad  by  aoa-alphabatle  eharaetars  :**); 

Tazt_ZO .  MawJLlaa ; 

Tast~ZO .  PutT">" ) ; 

TartJZO .  C>at_ltiaa  (Buf f ar ,  Stringjbaogtb) ; 
if  Strlag  Lanoth  >  llax_llaaMj[iaikgtli 


than 

TaaEt_ZO .  l(aw_Liaa ; 

Tast_ZO.Put  ("Xaaa  ZD  troacatad  to  t 

Boffard.  .llaa:_Kam_laagth)  C 
Taaa_ZD  :■  Buffar(l.  .llax_llaaa_Daagth) ; 

Taxt_ZO .  llaw_Zdaa ; 

alaa 

Taaa_ZD (1 . . String  Langth)  ;»  Buffard.  .8trinq_DaBathl ; 
and  If; 
and  Gatjfaaa; 
pra^M  paga; 

—  »f » » ♦  M M n M I  t*t***n-+*+**+n-n niiHuniHtttiii-untiiii 

—  Claars  aeraaa  with  DBC  VTln  control  codaa  aad  pata  bordar  at  top. 


prooadora  Claar_jleraaa  (WithjLiaajOf  :  ia  oharaetar)  ia 
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CL8  :  oonataat  atriag  :• 
bagia 


ohar«et«r'Tal(27)  S 
chaaacf  r *  (27 )  ft 


-t2J"  ft 
"IH"; 


SwKt  X0.2ut<CU); 


for  1  in  1  . .  72  loop 

font JCO. Put  (llith_LlaajO£)  ; 
and  loop; 


and  Claar  fcraan; 


prooadiaxa  Bandar  la 


bagin 

Vaat_IO .  liaw_Liaa; 

VoBt~XO.PvtT"*o2t«ara  Bnpport  Siaing  and  Batianting"); 
vaBt_XO .  lia»_Xilaa ; 

Vact^XO. Pvt  ("with  Mark  XX  Ponetion  Pointa  for  Oraela  Databaaaa") ; 
font  XO.Maw  Lina; 
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—  1 1  Hf  ***************  1 1  ♦  M  ♦«  ♦>♦♦»»»<  I  M  1 1  I  III**** 

—  0«t  options  for  aisiag  sad  astlastlng 


prooadasa  OstjOptioa(Psojaet_Optloa:  oat  ehsrsetsr)  is 
Optioa  :  oharsotss; 
bagia 


Saat^XO .  llOir_Liaa ; 

TaKt__XO.Pat("(8)isa,  (■)stlaata,  (A)etaal,  (Q)alt,  (?)  :  "); 
Taxt_,ZO. Gat  (Optioa) ; 

PxojaetjOptioa  :■  Optioa; 


asoaptioa 

idiaa  Vaact_IO.Data_lrsos  ■> 
PsojaetjOptioa  :■ 

aad  GatjOptioa; 


—  ♦♦■H  1 1 144  t  >  ♦  f-H-f 

—  Pootar  for  ania  psogsaai 


psocadoza  Footaz  is 
bagia 

Vast JtO .  Mawjbiaa ; 
TastJZO.PatT''KMD  rP2"); 
Vast^IO .  MawJLiaa; 
aad  Footaz; 


pzagM  paga; 


bagia  —  FP2 

Claaz_8czaaa  (With_LiaajOf«>'  ■' ) ; 

Tazt_ZO.Pat("  FP2  ");  “ 

FP2_ialp.'^^«aa*» 

Oiuc  ma  KaaM  L«agth-7<l-l.  .llaz_Fila_ltaBa_baBgth)  :>”FP2.8X«"; 


L:loop 

GatjOptioa  (PzojaetjOptioa) ; 
oaaa  PzojaetjOptioa  ia 

wtaaa  '8'  I  's'  ■>  FP28 (Pzo jact) ;  —  8iBa 
wbaa  'B'  I  'a'  »  FP2B (Pzo jact);  —  BatiMta 
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irtMn  'A'  I  'a'  ■•>  FV2A(Pxojaet);  —  Aotual 

whaa  'Q'  I  'q'  ■>  IP2V(Projaet} ;  —  Sava 
aslt  L; 

whaa  ethara  ■>>  PP2H  (PP2_Halp_P1 1  anaaa) ; 
aad  oaaa; 

Claar__8craaa  (Wlth_ZJjia_Of ■>'  ■' )  ; 

*a*tJtO.Pttt("  FP2  "); 

aad  loop  L; 

Pootax; 

aaeaptioa 

whaa  Taatt_XO.Bad_Krsor  >>  aull; 
aad  rP2; 


aaparata  (PP2)  prooadoza  FP2A<Projaet:  ia  out  PcojaetjList.Xtist)  ia 
pragpaa  Optijaisa  (Tiaa) ; 

Projact_lloda  :  ProjactJiddajtypa; 

Piniahad  :  ehaxaetar  :■  'W'; 

procadora  PP2AG(Pzojact:  la  oot  Pxojaet_llOda_typa)  la  aaparata; 
proeadoxa  PP2AP  (Pro jact :  la  out  Pxojaet_ltoda_typa)  la  aaparata; 
pragma  paga; 


bagla  —  PP2A 

ClaarjBcraaa  («lth_LlaajO£«>'  -  ' )  ; 
Part JFo. Pate*  PP2i  ");” 

Taxt_IO .  8klp_Llaa; 


6at_8SR  (Pro  jaet_lioda .  SSRJlam) ; 
Gotjraaa(Projaet_Moda.  Vaam_ZD) ; 


PamtjEO .  NawjLlaa; 

Paxt_ZO .  Nawjblaa ; 

*oaEt~ZO.PutT''Por  Sni”  C  Pxojaot_lloda.81R_llum  C 
”,  Paaa:”  ft  Projaot^Woda.Tmam_ZD) ; 


PP2A6(ProjaotJloda) ; 
Pro  jaetjblat .  Coaatxaet 
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(Tli«JXt«a  ■>  Pro  j«ct_Moda,  AndJIhoJEilat  ■>  Pro  joct) ; 
PP2AP  (Pro  joct_llOdo) ;  ~ 

•ad  PP2&; 


a^parato  (fP2 . PP2&) 

proe«dar«  rP2JUS  (Project :  In  out  Proj«et_llod*_typ«)  ia 
pragaa  Optiada*  (Tiaa) ; 

pragaa  pa^; 

—  HI «  >  Mt  MM  m  I  «  H  I  I  Ml  1 1  M  ♦«  H  4-f-f 

—  Dlaplap  baadar  for  aaia  procadara  PP2jyB 


prooadura  Haadar  la 
bagln 

Taxt_XO .  liaw_Lina; 

Tazt_IO .  MaaTLlna  ; 

Taxt~IO.Put 

("Pozaw,  raporta,  and/or  tablaa  "  t 
-MDDKD,  aUMOB},  or  DBLinO  to  aiqpport  tha  8IRi"  « 

Pro  jaet .  8SR__lluB) ; 

Taact_I0.1law_Zdna;  “ 

VacKt__ZO.Put 

("jmDID:  eraatad  a  cooplataly  now  fora,  raport,  or  tabla”); 
Tart_IO .  llaw__Llna; 

Tazt  10. Maw  Xdna; 


T«Et__I0.Put 

("CHAUGB):  cooponanta  within  aziatiag  fom. 


raport,  and/or  tabla”). 


Tast_I0 .  Maw__Lina; 

Tazt_IO.Pttt 

(”i.a.  ADD,  CBG,  OIL  blocka,  fialda,  and/or  atapa  nf  a  foot. ”}; 


Taxt_Z0 .  llaw_Lina; 

Tast__X0 .  llaw_Ziina ; 

Tart]|jo.Put 

("DBUTKD:  coa^lotaly  dalatad  asiating  foa. 


raport  and/or  tbi.") 


Taxt_X0 .  Waw^Idna ; 

Vazt^XO .  MawjLia; 

Tazt_XO.Put(”lntar  data  in  thia  forat:  000.0"); 
Tazt_XO .  MawjLia ; 
and  Maadar; 


praga  paga; 

—  ♦♦♦♦♦♦M-MMIMfl^M  tM♦MMMMMM■l■♦♦♦»♦■H^4MMM♦4■M4^M■■l■4»♦^^f 

—  Gat  hetal  Piinetia  Pointa  8upportad 


proeadiua  Oat_Aetal  ia 


hnpjChar  :  eharaetar; 


bagla  —  G«t_Jketual 

Gat_Cod*_1llu : 
bagln 

Vaxt_XO. Put  ("Calendar  waka  alapaad  diiHng  coding  >  "); 
rioatPt_lO .  Gat  (Pzo  jaet .  Codajika}  ; 
oscaptiob 

whan  TaKt_ZO.I>ata_Krcoc  ■> 

Ttta:t_ZO.Put ("Katac  data  in  this  fosaat:  000.0"); 
Taact_XO.Put  (A8CXX.BKL)  ; 

Sast_XO .  MoMMCtiaa ; 

Ta«t_XO . Put  ( "Calandar  wtstdcs  al^sad  during  eodiag>"); 
PloatPt_XO.  Gat  (Pro  jaet.  Coda_1lks) ; 
and  GatjCoda_llka; 

Gat JPaat_1lks : 
bagin 

Tast_XO. Put ("Calandar  uaaka  alapsad  during  tasting  >  "); 
rioatPt_XO . Gat (Pro jact . Tastjiks) ; 
axeaption 

whan  Soact_XO.DataJBrror  «> 

Vart_XO.Put ("Bntar  calandar  waaka  in  thia  foxaat:  000.0"); 
Tazt_XO. Put (ASCXX . BEL) ; 

Taxt_XO .  HawjLiaa ; 

Taat_XO. Put  ("Calandar  waska  alapsad  during  tasting  >  "); 
rioatPt^XO .  Gat  (Pro  jaet .  Xastjnes) ; 
and  Gatjrast_1lks; 

Gat jCoda_Brs : 
bagin 

Taxt_XO.Put  ("Man  hours  ^ant  on  coding  >  "); 
rioatPt_,XO . Gat  (Pro  jact .  CodaJBrs)  ; 
axeaption 

whan  Toxt__XO.DataJirror  ■> 

Taxt_XO.Put ("Sntar  aan  hours  in  this  fornat:  000.0"); 
Toxt_IO.Put  (ASCXX. BEX.)  ; 

Tast__XO .  Mow_Lina ; 

Tast_XO.Put ("Man  hours  ^ant  on  coding  >  "); 
rioatPt_XO . Gat (Pro jact . Coda_Brs) ; 
and  GatjCoda_Hrs; 

Gat_Tast_Hrs : 
bagin 

Paxt_XO.Put  ("Man  hours  ^ant  on  tasting  >  "); 
rioatPt__XO. Gat  (Pro  jact .  TastJBrs) ; 
axeaption 

irtian  Taact_XO.Data_Esror  ■> 

Taxt_XO.iiow_Lina; 

Tast_XO.Put("Entar  tast  ■an'-hours  in  this  foxaat:  000.0"); 
*axt~XO.Put (ASCXX. BEL) ; 

Taxt_XO . Maw_Liaa; 

Taxt  XO. Put  ("Man  hours  spant  on  tasting  >  "); 
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rio«tPt_IO . G«t (Project . T«st_Hrs) ; 

•nd  G«t_T«st_Hrs; 

G«t^Punction« : 

for  Functions  in  8W_Funetlon__typ«  loop 
Gst_Svppost : 

for  Siqpport  In  8lf_Support_typs  loop 

Block: 

bogln 

T«zt_IO.Pttt 

(SW_Functlon_jtypo' lasgo (Functions)  t  t 
8lf_8upport_typs*  (sags (Support)  C  "  >  "); 
if  Svqpport  •  TOCBL  thsn 

Pro joct.nFPs(TOCAL, Functions)  :■ 

Projact.t)FPs(ADDD,FunctiMis)  -f 
Pro joct .  UFPs  (CHkWSBD,  Functions)  -f 
Pro  jsct  .XJIPs  (OBXJRED,  Functions) ; 

Nstursl_ZO . Put (Pro js«t . CFPs (XOEBL, Functions) ) ; 
also 

Mstursl_lO.Gst  (Project .UFPs  (Sijpport, Functions) ) ; 
and  if; 

and  Block; 

and  loop  Gat_Support; 

Taxt_ZO . Haw^Idna; 

Tazt^ZO .  Kaw^Itina ; 

and  loop  GatJTunctions; 

AnyjChsr  :*  Gat_Option(''Any  char  to  continue  >  "); 
and  Gat^Bctual; 
pragsM  page; 
begin  »  FP2AG 
Baadar; 

Gat  Actual; 


and  FP2AG; 


separata  (FP2.FP2A) 

procedure  FP2AP (Pro jact :  in  out  Projaot_llOda_typa)  is 
pragaa  Optiaisa  (Tiaa)  ; 


no 


1; 


l>ata_ril«  :  T«zt_XO.Fll«_typ«; 

Col  :  ToztJIO.PoaltiTOjCouat 

pr«9u  pago; 
bogin  —  FPZAP 

VoKt JXO. Croat* (ril«v>  Data_Fil*, 

Mod»B>  T*xt_IO.Ottt_£il*, 

Wmi— >  ”a*r»  c  Pzojioet.SSRJlu*  c  ".dat"); 
V*zt_ZO.8*tj0atpat  (ril*«>  Data^Pil*); 

T*zt_ZO . Put (Pro j*ct . V*aa_ZD) ; 

T*xt_ZO.Put  (Pro j*et .  SBlJMii*)  ; 

PloatPt_ZO .  Put  (Pro  j*et .  Coda_1fks) ; 
rioatPt~ZO .  Put  (Pro  j*et .  Tastjiks) ; 

PloatPt_ZO . Put (Pro j*et . Cod*_Hrs} ; 

PloatPt  JEO . Put (Pro j*ct . T*at_Hrs) ; 

SW__8vpport : 

for  Svfport  in  8lf_8i9port_typ*  loop 
8N_Puaietlona : 

for  Functions  in  8W_Funetlon_tpp*  loop 
If  not  (fv^port  -3  TOTAL) 
than 

Col  :•  Taact^ZO.PositiuojCount  (  int*g*r(Col)  ‘f  5  ) ; 
T«Kt_ZO.  8*t^Col  (To->  CoT)  ; 

natural  JZO. Put (Proj*et.nFPs(St^pport, Functions) ) ; 
•nd  if; 

•nd  loop  8ir_Functlons; 

•nd  loop  8W__8vpport; 

T*xt_ZO .  il*w_Zd.n* ; 

T*xt_ZO.CloM (Data_Fll*)  ; 

T*rt_ZO.  8«tj0utput  (Fil*B>  TsKt__ZO. 8tandsrd_j0tttpot} ; 

AayjChar  G*t_Optlon('’Aiqf  char  to  continu*  >  "); 

•nd  FP2AP; 


pragM  paga; 

••parat*  (FP2)  prooadura  FP2B(Proj*ot:  in  out  Psoj*et_JList.Zd.st)  is 
pragaa  Optics*  (Tiaa) ; 

Proj*ct_llods  :  Proj*ct_HodajtFp*; 

ZiSstjChar  :  natural  :■  0; 

8IR_8is*  :  natural  :■  0; 

procodur*  FP2BT(TCA  :  in  out  TCAjt]rp*)  is  saparata; 
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bagln  •>  IV2X 

ClMrjBcBMn  (1flth_  .in«_0£>>'  -  ' ) ; 
TttstJEb.PutC  rP2i  "); 

i£  Froj«otJList.IaJMull (Project) 

than 

Taact_XO.Put("llo  projaeta.") ; 

•la* 


caa* 

0«tjOptlon('*Do  you  want  to  chang*  dafault  TCla  (T/M)  ?  ")  la 
wbM  'T'  I  'y'  •>  rP2IT(Froj*et_M0da.TCX); 
uban  othara  ■>  null; 

and  oaaa; 

Frojaet_Moda  Frojact_ZJLat.Baad_0£(Projact) ; 

Tast^IoTPutC’Pox  SIR#**  &  Pxojact_lioda.8SRMuA  & 

",  and  taam:  "  C  Projact_lloda.Taaa_XD)  ; 

Taxt__IO .  llaw_Xilna ; 

for  1  In  xauaraa  1 . .  SXR_llum_Xiangth  loop 

If  ProjactJNoda.SXRjPu8i(l)  /«  '  ' 
than 

ZMtjChax  :■  i; 

•xitT 
and  If; 

and  loop; 

for  j  In  SIMrunctlonjtypa  loop 
Tazt_IO .  llaw_Lina; 

Past_IO.Put  ("Ria  asiating  baaalina  baa  : 

for  i  in  rararaa  SWjBtvportJbypa  loop 

liatural_io.Put  (ProjactjPoda.XlVPa  (1,  j) )  ; 

Twct_lO.Put("  -"); 

TaKtJIO.Pot(Slf_8upportJbypa'iaaga(l)  t  "  "); 

Vast^ZO.Put  (8ir_runctlonjtypa'  iaaga  ( j) )  ; 

if  1  ■  TOXAX. 
than 

T«ct_ZO.Put 

ud  SSRi"  c  Projact_Noda.8BR_lliaa  s  "raqulraa 
alalf  j  /«  TRAN8ACTZ0m  " 
than 

8IR_8iaa  8BR_8isa  ^  (  Projaet_Moda.arPa(i, j)  ); 


112 


•nd  if; 


«Mt JCO .  MMrJLiM  ; 

•nd  loop; 

•ad  loop; 

foxt_ZO .  Mow^Zdno ; 

Tozt_ZO.Pttt 

{"tb»  also  of  SXRi"  C  Pxojoetjtodo.SXRJta  c  ”  ia  C 

natural' iaaga (SKRjSiao)  C  **  Mark  ZZ  ruaction  Pointa."); 
faxt_ZO .  liaw_Zdaa ; 

V«st_ZO.Pttt  ("Batiaatad  affort  ia  O  "  C 

‘'ataff-houra,  O  “  c  "ealandar  uaaka.*); 

Taxt_ZO .  Haw^Liaa; 

kayjChar  :■  GatjOptioa(”Aay  charaetar  to  coatinua  ...  **}; 

•ad  if; 

•ad  rP2X; 


pragaa  paga; 

aaparata  (rP2.rP2B)  proeadura  rP2BT(  fCk  :  in  out  XCkjtypa)  ia 
pragaa  Optiadaa  (Tiaa) ; 

Count  :  natural  :>  0; 

Projact^Woda  :  Projaet_aoda_typa; 

—  M  H  H»l  I  M  M  I 


proeadura  Haadar  ia 
bagia 

Tast_zo.Put 

(” (▼•!••)  of  Taetaaioal  Coaplaaity  kdjuataaat  eharactariatiea: ") ; 
Tart_ZO .  llaw_Zdaa; 
and; 


bagia 


for  i  in  SCkjCharaetariatica  loop 
Count  :■  Count  4-  1; 

Tast_ZO. Put (natural' iaaga (Count)  a  ("); 
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T«ct_XO.Pttt(TC&_8e«l«jtyp«'iMg«(Pzojttetjiod«.Tai(i))  c  ")  "); 
Ta3Bt_I0.Put  (TCA._Gt»aract«ristlcs'  iaaga  (i) ) ; 

T«Kt_XO .  ll•w_XJLa• ; 

•ad  loop; 

•ad  FP2XT; 


•«p*rat«  (IV2) 

pxooodux*  FP2H (Fg2_Balp_Piloni«a ;  atrlag  "^p2.hlp*')  Is 

H«lp_ril«  :  V«xt_XO.Fil«_typtt; 

HalpJLiao  :  Llaajbypo; 

XiSstjChsr  :  astussl; 

AnyjChss  :  chssaetos; 

bogla 

Clasr_8efsn  Otith_IdaajOf»>*  -  ' ) ; 

T«*t_10.Put(”  ; 

T«xt_XO . Op«n (B«lp_ril«, ToztJZO . Xa_ril«, IT2_H«lp_rll«aaaM)  ; 
Toxt^XO . Got_Zda« (B*lp_Fll«, B«lp_Llao, LsstjChss) ; 

Balp: 

whllo  Xkot  T«xt_XO.BadjO£_Fil«  loop 
f«zt_XO .  NawJLlaa ; 

T4ttt~X0.PtttTB*lp_Lia«  (1 .  .iMtjCSias) )  ; 

Soxt__XO .  Gat_XdiM  (H«lp_Fll«,  B«lp_Lia«,  La8tjC2uir} ; 

•ad  loop  Holp; 

Tost_XO . Cloao  <HolpjFllo) ; 

•xcoption 

whoa  Toxt_XO .  Wsmajrror  >> 

Tozt_XO .  ll«w_Liaa ; 

Toxt_XO .  ll•w_Xda• ; 

Tozt_X0.Put(FF2JBalp_FlloaaaM  ft  ”  aot  fouad."); 

Toact_XO .  NowjEdaa ; 

AayjChar  :*  Got_Optioa("hiqr  eharaetax  to  contiauo  ...  "); 

whoa  Fozt_XO.Kad_Krsor  ■•> 

ToxtJXO .  lla(w_Lino; 

AayjChar  :■  GotjOptloa("hiqr  ehasaetos  to  contiauo  ...  "); 
•ad  FP2B; 


••parat*  (FF2)  proooduzo  FF28(Fxojoct:  la  out  Fsojoet_Xilst.Xiist)  is 
psagaa  Optiaiso  (Tiaa) ; 
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Proj«ot_lloda  :  Proj«et_llodajkyp«; 

Mpp_Uodm  :  AppJKodhJtjpm; 

CttrsMkt_App  :  .  List  :■  JkppjULst.MullJList; 

J^pa  :  App_List.Llst  :■  Lpp_List.Mull_List; 

proosdoBS  n2S6(Jkpp  :  in  out  Lpp_Xiist.List)  is  sspsssts; 

psoosdiszs  rP28X(App  :  ia  out  App_List.Ust)  is  sspsssts; 

proesdars  rP28R(Lpp  :  ia  out  JkppjList.List)  is  sspsssts; 

pssgM  psgs;  " 


bsgia  —  FP28 

Clsssjlesssa (With_Lias_0£a>' -' ) ; 

TSBt_XO.Pat(”  n28  **); 

Tsst_XO.  8kip_Xdas; 

Gst_8XR<Pso  jset_llods.  8IRJtua) ; 
GstJtssai(Psojsct_llods.TsaBjXD) ; 

Tsxt^XO .  ]loir_Lias ; 

Vsxt__XO .  MswJLias; 

Tszt'xo.PutCPos  8BRi**  C  PsojsetJlods.8KR_llaai  8 
~  Tssa:**  c  Psojs^JlOds.Tssa_XD); 

PP286(PsojsetJio<ls.J4ips) ;  Gst  siss  of  psojset 

Pso  jset Jliist .  Coastsuet 

(Tbs_Xtsa  ■>  Pso jsct_llodo,  Ladjrhs_Ust  ■>  Psojset) ; 
Casssot_J^  :■  Psojset_lioda.J^po; 
whils  aot  J^_List.Xs_MUll(Casssat_Lpp)  loop 
Sstsset:  dsclsss  J^_sseosd  :  8pp_ltods_t]rps; 
bsgia 

8pp__sacosd  :  ■  J^^List .  BsadjOf  (Casssat_J^) ; 

if  J^_soeosd.TirP(DKLraD,TMUI88CfXCM8)  ■  0 
tbsa 

PP28X(Casssat  App); 
sad  if; 

CasssBt_J^pp  :  >  AFP_List .  TsilJDf  (Cassaat_App)  ; 
sad  btsset; 
sad  loop; 


US 


Cttrrtt&t_App  :■  Proj«et_Moda.Anp«; 

«hll«  aot  J^p_Xd.st.Zs^Mttll(Cuxx«nt_J^p)  loop 
FP2SIt(Cttrr<ont_l^) ; 

App_llodo  :>  App__Xd.«t.HMid_p£(Carro&t_Jkpp)  ; 

for  1  In  8ll_8i9poxtjtyp«  loop 

for  j  in  8IMraactlon_tppo  loop 

Projoct_llodo.arPa(i,  j)  :> 
Proj«ct_lfodo.OIPo(i,  j)  -f  appJNOdo.OTPa,  j); 

•nd  loop; 

•nd  loop; 

Cttrront_i^p  :■  J^p_Ll«t .  TnlljOf  (Corront .App); 

•ad  loop; 

Pro  jaetJEJist .  8«t_Httad 

(Of jnM_Llat>»roj«ct ,  To_TlM{_Zt«aiB>Proj«et_llodo) ; 
•nd  rP28; 


pragan  paga; 

••parata  (rP2.rP28)  proeadura  rP286(J^pp  :  in  oat  JI^_Zd.at.Llat)  ia 
pragaa  Optiadao  (Tiaw) ; 

—  Gat  Appa 


proeadura  Gat_i^  (8t9port  :  ia  8irjBapport_typa; 

:  in  out  J^_Xiiat.Xiiat)  ia 


J^_raeord 

Buffar 

8triag_Xiaagtta 
All  J^pa 
Pila  Kaaa 


App_Moda_typa ; 

Liaajtypa  :■  (othara  ■>  '  '); 
natural  :■  0; 
boolaaa  :■  faloa; 
Pila^ltaaMjtypa  :■  (othara  ■> 


'); 


bagia  ~  amt_»pp 


$ 


Tast_ZO.  8kip_Lina; 
pragaa  paga; 
Oat_J^pa: 
loop 
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WLhmjKmmm  :■  (otters  ■>  '  '); 

Bttffox  :■  (otters  ^  '  '); 

Stet_XO . 

TSKt_Z0.Vut(8lljBnFportjtyps'iasgs(Si9port)  A 
AU^Apps  :■  trus; 

test  10.  GotlAns  (tef  for,  StrlnoJLsngth) ; 
rilo^teM  :>  Boffor (1. . 65) ; 

for  i  ia  1 . . 65  loop 
if  rilo_MBM(i)  /■  '  ' 

All_Apps  fslso; 
salt; 
sod  if; 
oad  loop; 

if  All_Apps 

ttea 

test  ZO.Kow  XiAs; 


also 

test_Z0 .  Put  (rilo_MSBM) ; 

^roeord.Ksas  :■  Fllo^Ksao; 

Jkpp^rooord. Stops  :«  StspjULst.ltoll^ZJLot; 
Spp_,soeord.Bloeles  :■  Bloek_J<ist.ltallJtd.ot; 
Jtpp_roeosd. OTP  (Support,  fraassetiOBS)  :■  1; 
Spp_raaord.orP(TOBSZi,Traasaetioas)  :■  1; 
Spp_Xiist .  Coastruot 

(Tte_ZtoB  ■>  J^_Boeosd,  tedJZte_List  ■>  Spp) ; 
oad  if; 

salt  Qot^Spps  whoa  All_Sppo; 
oad  loop  Got_J^ps; 
oad  Oot_J^; 


prsgM  psgo; 

—  I  M  M  H  M  M  >  M  H  1 1  M  I  »■»♦♦♦♦♦♦♦♦<  1 1  »♦♦♦♦♦■* 4  I 

—  Ij^aia  wtet  to  oator  for  ooob  support  typo 


prooodiiro  Baploia  (Support  :  la  SWjBvvportJtjpo)  is 
tegla 


esso  Support  is 


T«xt_ZO .  MafwJLia*; 

Tast_ZO .  llair__XilM  ; 

TWCt~ZO.PutT"*NOTI*  Mppm  to  bo  ADDID  will  bo  oisod  "  C 
"  by  analogy  to  oxlatiAg  Appa.”); 

Toizt_ZO .  llaiw_Lino ; 

ToaEt_IO.Put 

("Bntor  tba  filonaaaa  of  '  .FP2'  filoa  of  OKiatiag  Appa  ") ; 
VojEt_IO .  liow_Aino ; 

Toxt_ZO.Put 

("-aiailar-  to  tho  Appa  that  you  will  bo  dovoloplng  for  8ER 
Tort  ZO.Mow  Zdao; 


Tozt_ZO .  llow_Llno; 

Toxt_ZO.Pvt 

Cmtor  tbo  '  .TT2'  filoa  of  oziating  Appa  to  bo  CHAWCP 
Toxt^ZO .  llo«[_Z>ino ; 

whoa  OXUTKD  ■> 


Tost_ZO .  llow_Lino ; 

Tort^ZO.Tut 

("Bntox  tbo  '  .n2'  filoa  of  oziatiag  Appa  to  bo  DBUTID  :  "); 
To3ct_Z0 .  Mow_Zdao ; 

wbon  otbora  *>  null; 

and  oaao; 


and  Sxplaia; 


proooduzo  Boador  ia 
bogin 

Tost_ZO .  Mow^Jbina ; 

Tost_ZO .  llow__Zdno ; 

Tost_ZO.Put 

("ZDBMTZrr  APP8  TO  BE  ADDED,  CHADGKD,  OR  DBUTID  TO  SOPPORT  SIR"); 
ToKt_ZO .  Mow Jbino  ; 

Tost_ZO .  Maw_Zdao ; 

Tost_ZO.Put ("ADDD:  waana  croating  a  eeaplotoly  now  App.”}; 

Tost_ZO .  MowJLiao ; 

ToaEt_ZO .  Row_Zdao ; 

Tost_ZO.Put 

("CHAMBP;  aoaaa  tbat,  within  an  oriatiag  App,  you  aood  to  "); 
Tort_ZO .  Mowjidno; 

Toxt_ZO.Put ("  ADO,  CM6,  or  DBL  aoao  blooka,  fiolda,  or  atapo.  ”); 
Tort  ZO.Mow  Ztiao; 
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V«xt_ZO .  MawJLiiM ; 

VttictJIO.Pat  ("DBUCntD:  — n«  Cflapl«t«ly  deleting  an  aniating  Mpp.”); 
*azt~I0.1law_Lina; 

Tazt^IO .  MawJUna ; 

Vant_ZO.Put ("Hhan  antaring  uumm,  aatar  ona  par  pro^t.  "); 
Taxt^ZO .  Maw JLlaa ; 

Vast JZO. Put  ("So  axit  Sxoa  tha  proaptlag,  antax  no  £ila  aaa»."); 
Saxt^ZO .  Maw_Zdaa  ; 

SwEt~ZO .  Maw~Liaa ; 

SaxtJZO.Pttt 

("Mow  ehooaa  ona  or  noxa  of  tha  aoftwara  aupport  aetlona:"); 
SaxtJZO .  Maw_Liaa; 

and  Haadar; 


bagia  — ■  PP286 


—  Gat  hpp  naaa  and  avpport  action 

Gat_hpp_hetioa : 
loop 

oaaa  GatjOption 

("App  to  ba  (A)ddad,  (C)haagad,  (D)alatad,  (a)o  aK>ra  :  ")  la 

whan  'A'  |  'a'  >» 

Explain  (ADDS)) ; 

GatJ^  (ADDED,  J^}  ; 

whan  'C'  |  'c'  ■> 
bplaia  (CHAMGED)  ; 

Oatjkpp (CHANGED, App)  ; 

whan  'D'  I  'd'  -> 

Explain  (DELETED)  ; 

Gatjkpp  (DELETED, J^sp)  ; 

idiaa  otbara  axit  Gat_App_Aetioa; 


and  loop  Gat_J^_Aetioa; 
TOKt_ZO .  Mow_Lina ; 
and  rP28G; 


aaparata  (PP2.TP2S)  prooaduxa  PP28R(App  :  in  out  App_Liat.Liat)  ia 
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pragM  Optiadsa  (TIjm)  ; 


App_Kod«  :  App_Hoda_typa; 

—  I  H  I  ¥*******+*+^*t  M  M  i  M  m  H  ♦  I i M  M  ♦♦»>♦<«  «  «  H  11  f-H-H- 

—  iMdar  £or  rP2  8is«  RaqulxaMUt 


prooaduxa  Haadar  (App^Xaa*  :  in  rila_Maaa_typa)  la 
bagla 

Claax_8exaan(' ; 

Tast.XO.PutC  rP28R  "); 

Vaxt JXO .  liaw_Liiia ; 

Saxt_XO.Put  ('*8isa  of  tha  8SR  for  J^p:  "  S  AppJIaaa) ; 
Tast_XO .  llair_IdAa ; 
and; 


pragM  paga; 


—  ♦♦  M  I  >  M  M  ♦♦♦»»♦♦♦  M  k+*+++  ♦  M  ♦  ♦  M  ♦  H  H  »*4  H  n  Ml  H  M  ♦  ♦ 

Pro^ptar  for  rP2  81sa  Raqulraaant 


procadura  rP_Chaagad(nPP  :  in  out  OTPjbypa)  la 
Paaalnlng  :  natural  :«  0; 
function  Proapt^With 

(Quaatlon:  atring;  XdJiit:  natural)  ratum  natural  ia 

PunetionJPoiata  :  natural  :■  0; 

bagin 

Oat_FP: 

loop 

Block: 

bagin 

faKt_XO .  WawJLina; 

Tazt_XO . Put (Quaatlon) ; 
llatural_jXO.Gat  (runctioo^Pointa) ; 

if  roactioa_Pointa  >  Xdait 
than 

TOKt_XO. Put (natural' laaga(rnaotion_Polata)  s  "  & 

natural 'iaMga(Idait)  S  "  ruining,  ") ; 

alaa 

omit  Oat  PP; 
and  if; 
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•soaptioa 

iriMn  T«xt_I0.1>ata_Kzror  ■> 

f*st_IO.Put("llim  AM  IMnOBR"}; 

•nd  Block; 

*  ttod  loop  Got^FP; 

soturn  FonetioaJPolnta; 

r 

•od  Pro^pt_1llth; 
pra^  pagm; 

bogia  ~  IPjChaagod 

Bvppoxt: 

fox  Si^vpoxtod  In  AIM>BD  . .  DBLBTB)  loop 
Fuaetiona: 

for  Functionality  la  ZMFOTS  . .  OOTFDTS  loop 

caao  Svpportod  la 

wbaa  ADOKD  ■> 

Bawalnlng  :■  natural' XAST; 

whoa  CmilGBl)  ■> 

BaMalfilng  :■  aatural(  TIFF (XOCIL, Fuactioaality)  ); 
whoa  DBURBD  ■> 

Raoainlng  :■  natural (  OFF (TOCAL, Functionality)  )  •* 

natural  (  TIFF  (CHANGBD,  Functionality)  ) ; 

and  caao; 

caao  Functionality  ia 

whan  XMFTIT8  ■>  TIFF (Svppoxtod, Functionality)  :■ 

Prompt jrlth ("Bam  amay  trigger  STBFS  will  ba  "  C 
8ll_8i9port_typa'iaago (Supported)  C  ”,  Baaaiaiag); 

whan  BMTXTIB8  ■>  TIFF (Supportad, Functionality)  :<■ 
Frooptjritb("Bow  wmay  BLOCKS  will  ba  ”  C 

8M_8upportjtype'iaHige(8i9poxtad)  A  ",  Baaaiaiag); 

iritan  OUTPUTS  ■>  OFF  (Svpportad, Functionality)  :• 

Froaptjrith("Bow  anny  FIBZC8  will  be  ”  A 

SHjSipportjtype'iaMge (Supported)  A  ",  Baaiatnlng) ; 

idten  othara  ■>  null; 

and  caaa; 
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•nd  loop  runetlona; 
Tost_IO .  »«w_LiM ; 
•nd  loop  Svppoxt; 


•nd  njChangnd; 
pragaa  pngn; 

—  ■»  It  ♦  «  l-H-H-t-H-H  >  I  U  I  III  M  M  ♦  H  >  »44  M  I  H-H  t  »♦  *  1114 1  H  M  ««  H  »■»♦♦♦ 

—  rootnr  for  fP2  Sin  Snquixnaont 


prooodoro  Footor  (Jlpp_Maan  :  in  Tilo_Wwnjtypn)  is 
bogin 

Toxt^ZO .  MOw^Zdno ; 

Vozt^IO.Put  ("Sisod  Rsquirssmnt  for  App:  **  C  App_Wfs) ; 
Toxt_IO .  Mw^Zdno ; 

•nd; 


bogin 

if  not  App_Zdst .  Zs_Mull  (J^jp) 
thon 

App_Modo  :*  App_Zdst.Bo«d_Of (App) ; 

if  J^pp_Mod•.lnV(CBAllGB),XiUUI8ACTZW^  >  0 
tbon 

Boador  (J^ip_irodo .  Mssm)  ; 

irjCbugodTi^^pjiodo.urp) ; 

AppjList .  8otJHA«d(0f jrbo_zdst«>l^,  Tojrho__lts«p:i Appjodo) ; 
Footor  (J^_Modo .  Naan) ; 

•Isif  App_llodo.bFF(ADDBD,TMIISACIIOII8)  >  0 
tbon 

for  i  in  mPUTS  . .  OUTPUTS  loop 

App_Modo.UFP  (ADDKD, i)  :«  AppJVodo.UFP (TOTAL, i)  ; 

•nd  loop; 

App_Zdst .  8ot_Hosd (Of_Tho_ZdstB>App,  Tojrbo_Ztsa^>App_llodo) ; 
•nd  if; 

•Iso 

Tost_IO.Put("Bipty  App  list"); 

•nd  if; 

•nd  FP28R; 


with  Psttom^llstoh__Hogulsr_Bi7rossioo;  —  Boooh  Co^ponont 
paokago  GASP  is  now  Pattom_lUtGhjAogttlar_Baprossion 
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(Itwi  ■>>  ohax«ct«r, 

Zadmx  ■>  poaitiT*. 

Xtaas  ■>  atriag, 

Aay_ZtaB  ■>'?', 

BaoapaJCtaa  -> 

MOtjttaM  ■>'*', 

CXoausa_Ztaai 
StartjClaaa  ■>'['« 
StopjClaaa  ■>  '  ] ' , 

la_Kqiial  ■> 

pragM  paga; 


with  GUP; 

aaparata  {n2.W»2B)  pxooadusa  WP2SX  (i^:  ia  out  J^_hiat.Liat)  ia 
pragaa  Optiaiaa  (TiaM) ; 


typa  Part_typa  ia 
(1IDU._PARS, 
BLOCK_PhRr, 
riBU>_PhRT, 
TRIGGBRJOkMBJPAKr, 
STEP  MOMBBl  PARS) ; 


typa  Z«waljtypa  ia 

(  APPJtXVEL,  —  looking  for  triggar  at^a,  than  blocka 

BhOCK_ZXVEL,  —  looking  fox  triggar  atapa, 

than  blocka  and/or  fialda 

nKZi>_ZJmUt  };  —  looking  for  triggar  atapa, 

—  than  blocka  and/or  fialda 

Lawal  :  Lavaljtypa  :■  APP_£BVBL; 

8tap_ltoda  :  8t^_ltodajbypa; 
riaidjioda  :  riald_lldda_typa; 

■loek_lloda  :  Block^MOdajtypa; 

J^pp_ltada  :  AppJMdajtypa; 

Shajrila  :  Saact_ZO.rila_typa; 

Sha3>ina  :  Linajbypa; 

lad  Lina  :  natural; 


—  igaoxa,  coatinua  acaaaing 

—  block  datactad 

—  fiald  datactad 

— *  triggar  aaaa  datactad,  wait  for  at^  nuai 

—  atop  auabar,  triggar  atap  ZD  eoaplata 
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•acoaptlon 


whan  aRSP.Patt«ra_Mot_Found 
Sad  Data  :■  0; 


and  Sean  Lina; 


function  PartjOf_J^(Curxant_Liaa  :  in  Liaajtypa; 

Currant_liaa__Bnd  :  ia  natural) 

xatum  Part_typa  ia 


Tha_Data  :  Linajtypa; 

BadJData  :  natural; 

Part  :  Partjtypa  :>  llull_Part; 

For_8tap_Langth  :  natural  7; 

For_8tap__lluabar  :  Zdnajtypa; 

For_Triggar_Langth  :  natural  :«  6; 

ForJfriggar_Kaaa  :  Z>ina_typa; 

Forjrlald_Ziangth  :  natural  :«  18; 

For_Fiald_Maaa  :  Zdna_typa; 

For_Block_JLangt)i  :  natural  18; 

ForJSlock^HaaM  :  Linajtypa; 

8tart_Hara  :  natural; 

pragma  paga; 
bagia 


For_8t^_lluabar(l.  .ForjBtap_Laagt)i}  :>  "8TBP  ■  "; 

Scan__Lina <For_8tap_lfuabar,  ForjBt^JLangth, 

CurrantJLiaa,  CuraaatjLiaaJSBd,  VlM|_Data,  BadJData) ; 
if  Bad_Data  >  0  ”  ~  ~  ” 

than 

Part  8TBP_inMBBR_PSST; 
for  i  in  ranrarsa  1.  .llax_Wama_Langth  loop 
if  8topjroda.saao(i)  •  ' 
than  StartJBara  :■  l<f2; 
and  if; 
and  loop; 

8tap_lloda.Mama(8tart_Hara.  .lUz_Baaa__Langth)  :■ 

Tha_Data  (1 . . llan_llima_Langth-8tart_Ba«a*  1 )  ; 

and  if; 
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ror_Txigg«r_MUM(l.  .ror_Trlgg«r_Zi*ngth)  :■  "TXPK: 

8ean_ZJA* (r oc_Txlggttr_llaaa ,  Fox jrriggar_X«agth , 

ThiO_,LlM,  BadMCilno,  Tho^Data,  lad_pata) ; 
if  ladj)ata  >  0 
than 

Paxt  :>  TRIOGBR_llhMIJPARS; 

8tap_Moda.Naaa  ;■  Tha_Pata(l,  .llaajaaajanqth) ; 
and  if; 
pxagM  paga; 

rox_riald_MaM(l..Foxjriald_Langth)  :>  "nSXC  [0123456789]'*; 
8oanJLiaa  (rex_Fiald_llaaa,  Fox_riald_Ziangth/ 

Tha_Zdna,  8ad_Xtiaa,  nia_Data,  Bnd_I>ata) ; 
if  Kad_Data  >0  *"  “  ” 

than 

Paxt  :>  rilID_PhRT; 

FiaXdJNoda.Naaa  Tha_Data(l.  .liaz_llaM_Langth)  ; 
and  if; 


Pox_BlockJKa«a(l.  .rox_Block_Ziangth)  :■  "Slock  [0123456789]”; 
8ean_Lina  (rox_Bloek_MaaM,  FoxjBlock^Langth, 

Tha_Xdna,Snd^Zdna,  Tha_Data,  lnd_Data) ; 
if  Bnd^Data  >  0 
than 

Paxt  :«  KUXacjPJURT; 

Bloek^Moda .  MaaM  :  ■  ThaJData  (1 .  .Hax^llaaMiJhngth) ; 
and  if; 


xatttxn  Paxt; 
and  Paxt_Of_J^; 


pxagaa  paga; 


bagin  —  FP28X 

hppjidda  :«  App_Zti0t.BaadjOf  (8pp); 
fox  i  in  1.  .llaa:jrila_Naao_Xiangth  locp 

if  J4ip_lloda.ll«Ba(iT  /-  '  ' 

than 

FixatjChax  i; 
axit; 
and  if; 
and  loop; 

fox  i  in  xaraxaa  1. .Maxjrila^Maaa^Langth  loop 
if  hppjloda.lfaM(i)  ” 

than 


126 


LaatjCStar  :■  i; 

•sit; 

•od  if; 

•nd  loop; 

Soxt_IO .  ltaMr_LlM  ; 

TOBt_Z0.Pttt  ("Oponlng  "  4  4pp_llod>.1li—  (rirotjChar.  .LaatjChar) ) ; 
VostJZO.Put  (**,  and  goading") ; 

VaKt_IO .  llaw_zajM ; 

Tast~ZO.Opaa 

(fSajrila,  Ta3Et_I0.Ia_rila, 

App_Noda .  Maaa  (Flrst_Char . .  LaatjChar)  ) ; 


nirtt_Flla: 

whlla  not  Ta9Et_I0.Knd_0£_Flla(Tha_Fila)  loop 

Taxt_ZO.Gat__Llaa(Tliajrila,  ZbajULna,  Bad_Liaa)  ; 

Z>iiia_lluabar  ZtlaaJFunbar  4-  1; 

if  Lina_lfuafaar  aod  100  >  0 
than 

Taxt_lO.Fut  (**Z>ina  #"  4  natural ' ijaaga  (Zdiia_lluabar) ) ; 

Vaact^jo .  Mow_Llna ; 
and  If; 

pragma  pago; 

oaaa  FartjC>fJlkpp(thaJUina,  BndJLina)  la 
whan  BLOCK_FJURX  ■> 

Block_Jfoda.8tapa  :■  8tap_Zdat.llall_liat; 
Block_Moda.Flalda  :>  Fiald_Zd.at.llttll_Zd.at; 

BlockJLiat .  Conatruct  (Zha_ZtaBi^^lock_lloda  , 

hadjrha_Zdata>>8pp_ltoda.Blocka  ); 
i^pp_llOda.gFF(TOC4L,BMTZTIS8)  :» 

A^_Noda.QFP(TOXhL,nTITlX8)  *  1; 

Ziaral  BLOCK_ZJBVBL; 

whan  FIBZi)_FART  ■> 

Fiald_lloda.8tapa  :■  8tap_Zdat.>all_Zdat; 

Fiald_Zdat .  Conatruct  (»ha_lt  MiK*Fiald_lteda  , 

hnd_Tha_Zdata>Bloek_lloda.Fialda  }; 
hpp_lloda.UFP(TOThL,OaTFOT8)~:ai  ~  ~ 

8pp_Moda.OFF(FOK8L,OOTFOS8)  4-  1; 

Laval":*  FZBLD_IBVBL; 

whan  8TSF_II0MBSR_FJ»X  *> 
oaaa  Zarval  ia 

whan  hpp_LBVBL  ■>  —  add  to  App_8TlF8 

8top_Zdat.Conatrttot (Tha_Ztamp>8tap_Moda  , 

had_tha_Zdat*>  hpp_MOdo.8tapa) ; 
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MppJKoOm.VniTOtML.XmXJTB)  :> 
App_Noda.UrP(TOUa.,Zl)PXJT8}  -f  l; 

whan  BLOCXJLIVSL  >>  —  add  to  BL0CX_8nP8 

8t«p_Xtist .  Construct  (Tha_XtavB>8tap_lfodo  , 

And_nMi_X>istB>  Block_lloda.8taps) 
8pp_lloda.nrP(T(»Ja.,IllP0T8)  :> 
Jlfp_Moda.TnT<TOIJa.,XllPOT8)  -¥  1; 

whan  rZB£D_LKVBL  »  —  add  to  riKLD_8TBP8 
8tapjblst .  Construct  (Tha_Ztaap>>8tap_lloda  , 

hnd_jrba_Zd.stw>  Flald__lloda.8taps) 

J4>p_voda.un(Tona.,iKraT8)  T>  ~~ 

8^jfoda.Drp(TOXihL,iiiFOT8}  -f  1; 

and  easa; 

whan  TitIGGKR_IOIMB_PARI  »  null; 
whan  1IDLL_PART  ■>  null; 

and  oaaa; 

pragma  paga; 

1£  not  riald_Llst.Zs_llull(Bloek_lloda.rialds) 
than 

riald_List .  8at_Baad  (0£jrha_List«>«loekjNoda .  rialds , 

”  “  ~ToJcte_ZtomP>ri^_lloda)  ; 

and  if; 

if  not  BlockjList.Xa_llull(J^_Moda. Hocks) 
than 

Block_Xdst .  8at_Haad  (0£jnia_Xd.stB>J^_llOda .  Blocks, 

”  ''Tojnio_Itoaia»loek_MOdo)  ; 

and  1£; 

and  loop  Thru^Flla; 

£or  j  in  8irjFunctlon_typa  loop 
Matural_IO.  Put  (J^JIoda  .UFP  (TOChL,  j) ) ; 
and  loop; 

'—8top_8croll  :■  6atj0ptlon(”Bi^  k^  ...  ”); 

hpp_List .  8at_Baad  (0£_Tha_List  » 

To_Tha_Itam  ■>  J^_lloda)  ; 

Taxt_IO .  Closa  (Thajrila) ; 

Tazt_IO .  llsiw_Xtina ; 

Ta9Et~ZO.Fttt  ("Closing  "  C  J^_lloda.llaam(FirstJChar.  .Xiast_Char) ) 
Fast  zo.Maw  Lina; 
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•seaptioa 


wta«n  T«fltt_IO . W— _Brtor  ■> 

Vast_ZO .  MmtJLIm; 

T«xt_ZO.Put(App_Moda.Maa*  c  "aot  found. "); 
•  fast  ZO.Now  Zdno; 


•ad  rP28X; 


pragM  paga; 

•aparata(FP2)  prooadoxa  rP2V(Projaet  :  in  out  ProjaetJLlat.Zilst)  ia 
pragaa  Optiaisa  (Tiaa) ; 


Pzojaet_lioda 
App__lioda 
ZaatjChar 
8QZ.  PUanaM 


Projaet_lloda  typa; 
Jkpp_ltoda_tyii; 
aatuxal  0; 

Plla_llaaa_typa  (othara  ■>> 


PP2y_Output  :  VaaEtJZO.rilajtypa; 
rP2V~SQL_rila  :  Tajct^ZO.PilajtnW'* 


prooadura  8aTa_8t^a (Stapa  :  la  8tap_Llat.Ziiat)  ia 
8tap_lloda  :  8tap_llodajbppa; 
bagla 

if  aot  8tap_Zd.at.la_Mall(8tapa) 
tbaa 

farajBtapa  (8tap_Liat .  TailjOf  (8tapa)  ) ; 

Taact_ZO .  Maw^Xiiaa; 

8tap_lloda  :■  8tap_Xiist.Baadj0f  (fha^Liat  •>  8tapa); 
Pa3Et~IO.Pat(8tap_ioda.ltaaa)7  ~ 

•ad  if; 

•ad  8aua_8tapa; 


prooaduza  fava^Flalda (Pialda  :  ia  Piald^Liat.Liat)  ia 
Piald_Noda  :  riald_lloda_typa; 
bagia 

if  aot  rialdJLiat.Ia_llall(rialda) 
thaa 

8aaa_rialda  (riald_Zd.at .  TailjOf  (Pialda) ) ; 

Past  XO.liaw  Liaa; 
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ri«ldJHOd*  :■  ri«ld_Ll«t.HMdjC>£(nM_xa.st  ■>  ri«lds); 
««zt_xb . Vut  (rialdji^ . Nan*) 
if  ^  8t«p_Liat.I«Jfall(rl«ld_lloda.8t«p«) 
than 

SavajStap*  (ri«ld_llod« .  Step*) ; 

•nd  if; 

•ad  if; 

•nd  8a'v«_Fialds; 

pxm^m  pmgm: 

prooadua*  8ava_Blocks (Blocks  :  in  Bloek_Xd.st.Z>ist)  is 
Bloek_lfoda  :  Block_lloda_t]rpa; 

bagia 

if  not  Block_List.Zs_Mull (Blocks) 
than 

JkppJfoda.DfT(TOZBL,KIITITIB8)  :« 

Bi^_Moda.OrP(TOIBIi,SiTITIB8)  *  1; 

8s'va__Blocks  (BlockJList  .TsiljOf  (Blocks) ) ; 
Vazt~IO.IIa«_Lina;  ~ 

Block_lioda  :«  Block^Ust.HasdjOf (Tha_XJ.st  >>  Blocks); 
Taxt_ZO .  But  (Blockjl^ .  Msaa) ;~ 
if  not  8tap_List.Zs_lfiill(Bloek_lfoda.8taps) 
than  8s'va_8tsps(Block_Hoda.8ti^); 

•ad  if; 

if  not  riald_ZJLst.Zajittll(Bloek_iroda.rialds) 
than  8sTa_rialds  (Block_lioda .  Fialds ) ; 

•ad  if; 
and  if; 

and  8saa  Blocks; 


psooaduxa  8sTa_Bpps (Bpps  :  in  i^p_Ziist.U.st)  is 
begin 

if  not  J^JU.st.Zs_lfull(Bpps) 
than 

J^ppJloda.OFP(T(>TBL,TRBllSACTZOII8) 

B^_Moda.UFF (TOTAL, TBBMSBCTZOm)  1; 

8sTa_J^s  (J^__List .  TsiljOf  (Bpps)  )  ; 

Tazt~ZO .  Mawjllna; 

Bpp^MOda  :■  Bpp_List.BaadjOf  (ThaJList  ■>  Bpps); 

TaaA_ZO.Fut(App_ltoda.lluMT;  ~ 

if  not  8tap_List.Zs_Moll(AppJK0da.8tapa) 
than  8sTa_8taps(Bpp_Mbda.8tsps) ; 
and  if; 

if  not  Block_List.Zs_Mttll(AiipJBoda.Bloeks) 
than  8sTa_Blocks(J^_lloda. Blocks); 

•ad  if; 

and  if; 
and  8ssa__i^ps; 

pxooaduza  80L  (Frojaot_xaeord  :  in  Fsojaet_Jfoda_tppa)  is 
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b*gla 

Xtet_IO .  li«ir_Xila«; 

V«ztJtO.PutT"IM8m  INTO  n2_8CR  VAUnS"); 

Vttxt_ZO .  llaiw_LllM; 

t«xt~ZO.Pttt  "  C  Proj«et_xtteozd.8SRJI0M  C 
Vaart._ZO.Put  "  C  Projaet_xaoozd.Vaaii^ZD(l.  .12)  C 
«ast~Z0.1lair_zajia;  “  “ 

taxt_ZO.Put("'"); 

rioatPt_ZO.Put(Projaet_xaeozd.Coda_Wks) ; 

Ta«t_ZoTput  (" ' , ;  “ 

»aart_ZO.Put("'"); 

rioatPt_ZO.Pttt(P«>jaet_xaeord.Vast_mEa)  ; 

*a*t_ZO. Put “  ” 

»ajrt_ZO.Put(""*); 

rioatPt_ZO.Put  (Pro  jact_tacotd.Coda_Hrs) ; 
iaxt_ZO.Put("', ");  “  ” 

*aJrt_ZO.Put 

rioatPt_ZO . Put (Pro jaet_xacoxd . Va8t_Hxs) ; 

Taxt_ZO.Put("' , "); 

Vast_ZO .  llaw_Lliia; 

llatural_ZO.Put  (Psojaet_raeozd.OPPs  UDOBD,  TMUISACTZOHS)  } ; 
Vast  ZO.Put(",");  ” 

1latus^_Z0.Put  (Pso jaet_saeoacd.xnrP0  (CaUMGSD,  VMMJUSVZOm) )  ; 
Vast_ZO.Put(",");  ” 

ltotusar_ZO.Put  (Psojact_sacozd.urP8  (DBURCID,  VMIIUCVZOMS} } ; 
Vast_ZO. Put “ 

llatusal_ZO .  Put  (Pxo  jact_sacosd.UVPs  (ADOBD,  IMVZVZX8) ) ; 
Vast_ZO.Put (", ") ;  ” 

llatusal_ZO .  Put  (Pxo  jaet_xaoosd.OPPs  (OnuSB),  BRZVZSS) ) ; 
V«t_ZO. Put  (","); 

ltatuxaI_ZO .  Put  (Pxo  jact_xaooxd.0rPs  (MURID,  BRZVZK8) ) ; 
Vast_ZO.Put(",");  ” 

Matuxal_ZO . Put  (Pxo  jaot_xaooxd.OVPs  (IPCTO,  UUVPUVS) ) ; 

Vast_ZO.  Put  (",");  ”  _ 

llatuxal_ZO. Put  (Pxo  jact_xaooxd.DPPa  (OUIRSB),  OOVPDVS) ) ; 

vast_ZO.Put  (", ") ;  ”  _ 

llatusal_ZO.Put  (Pxo  jaetjxaoosd.UPPa  (MUVID,  OWPOV8) ) ; 
Vast_ZO.Put  (", ") ;  ” 

ltotuxal_ZO.Put  (Pxo  jaet_xaooxd.QPPa  (JUXXD,  ZIIPDVI) } ; 

VOst_ZO.Put(",");  ”  _ 

Matuxal_ZO.Put  (Pxo  jaet_xaooxd.OPPa  (Ciawgg>,  ZHPOVt) ) ; 
VaBt_ZO.Put(*',");  ” 

llatuxal_ZO.Put  (Pxo  jaot_xaeosd.OPPa  (SCZSVB),  IMPUVt) ) ; 

Vast  10. Put  (");");  *” 
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S«Bt  ZO.Mwf  Lia«; 


Mkd  tOL; 

prrngmm  pmgm: 

bagla 

if  fro j*et_Zd.st .  Z0_liall  (Pro j«et) 


tbOD 

Vost^IO.Pot  ("MO  projoets  to 


•IM 

Projoet_Mod«  :■  Pro joet_Iii t .  MoadjOf  (fhojAt  ■>  Projoet); 

for  i  la  rttvorao  1 . .  fBR_Miai_Xioogth  loop 

if  ProjoetJModa.8SR_Mim(i)  /■  '  ' 
than 

ZtMtjChar  :«  1; 

•sit; 

•ad  if; 

•ad  loop; 

T«3Et^Z0.CrMt«(Pil«  PPfVjCXxtpot, 

**  Mum  »>  "fp2old."  i 

Pro  j«et_Mod« .  8III^M«bi(1  . .  ZiaatjChar)  ) ; 
T«zt^ZO.8«tj0tttput(Pll«  ■>  PPfVjOotpot) ; 

for  i  ia  1 . . 72  loop 
»«flrt_IO.  Put  ("-"); 

•ad  loop; 

T«ct_ZO.Pat("SIR  t"  «  ProjaetJtoda.SntJta  •  ",  ”); 
Tast_ZO.Put  ("T««a:  "  C  Projact_Hoda.Taaai_XD) ; 

Vttst__XO .  MowJEdaa ; 

for  i  ia  1 . . 72  loop 
*o«t_IO.Put("-") ; 

•ad  loop; 

if  aot  AppJLiat.Zo_Mttll(Proj«ot_ltoda.Mppo) 
tbaa 

tovo  J^po(Proj«ot_Moda.Jkppo); 

•ad  if? 

fOL_rU«fMM(1..3)  :>  "oar"; 
for** i  ia  1  . .  tntJtar^Ungth  loop 
if  ProjM«_ModaTsBrNim(i)  >  ' 

Lut  Qiar  :■  i; 
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•sit; 

•nd  If; 

•Bd  loop; 

SQi:.jril«iiaM(l.  .7-fLutjC3wx)  :>  "ms**  C 

Psoj«et_llodo.tlR_MisR(l.  .XtOstjChas)  t  ".aql**; 

TMEt_io.cxMt«(rii«  •>  rv2v_«QL_riift, 

~  Kmo  ■>  SQLjFiloiiMO) ; 

Mst_XO.8otj0atpat(ril«  rP2VjB0L_rila) ; 

«aL(PBoj«et_llodo)  ; 

S«st_Z0.8«t_0ittput  (ril«  ■>  VastJCO.StaadaxdjOvtpttt); 

Vost_ZO .  llair_UAa ; 

Tost  10. Put 

("Now,  login  to  SQLPLaS  and  STMT  SSR"  C  Pro j«et_HOda . SBRJIun)  ; 
•nd  if; 

•nd  PP2T;  —  in  apito  of  aaliasi 
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